Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture & Design - SWD391 - Coggle Diagram
Software Architecture & Design - SWD391
Chapter 4: Object Oriented Paradigm
4.1: Overview
Introduction to object-oriented
Popular since 1980's
Three Principles
Polymorphism
It includes:
Override
Overloading
Refer to ability of an object to behave differently and assume different forms based on its inheritance hierarchy
Translate it is call multiple form
Inheritance
A class can inherit from its base class
Inheritance allows software reuse, hence improving the effectiveness of software development
Encapsulation
Often call information hiding
It separate interface from implementation by hinding the implementation details
Flexibility in design, easy teamwork working.
OO Software Engineering
OO Analysis
OO Programming
OO Design
A very Poppular design approach, applies to many of the software architecture styles
OO programming language: C++, Java, C#
Use of OO
All other architecture style can be described using OO
Should be used as a methodology
Although treated as an "architecture style" in the book
4.2: Introducing the object-oriented paradigm
4.2.2: Relationships
A partial list of relationship
Instance Level Relationship
Association
Nomaly bidirectional
Is a connection between classes, and a semantic connection between objects of the classes involved in the association
Aggregation
A kind of "whole-part" relationship
In UML, aggregation is represented using a hollow diamond arrowhead
Parts do not have to share the same lifespan as owner
Is a special case of association
Composition
Composition is a stronger variant of the "own a" relationship
Requirement: the lifespan of "Components" and "owner" involved in a composition relationship must be same
Is represented using a solid diamond arrowhead
Class Level Relationship
Realization
Generalization
General Relationship
Dependency
It very complex!
Differences between composition and aggregation
Attempting to represent real-world whole-part relationship, use composition
Representing a software or database relationship, use aggregation
Composition vs Inheritance
Use the inheritance relationship only when the derived class "is-a" base class
Use the composition can be used to model the "has a" relationshi[ among class
OO paradigm provide two different approaches for reuse a design: composition and inheritance
4.2.1: Class and objects
Objects
Is an instance of a class
Class
Consists of three elements:
A list of operations
A list of attributes
A class Name
Is group to gether related data and their operations
Defines the attributes and behavious share by all of its object
4.4: OO Design
Step 1: CRC Card Approach
How to use
The Team examine use case one by one
When to stop?
When get to “private” details with no need of collaboration with other classes
When use case are solved, examine each responsibility of each class, repeat the same process
Facilitator starts the process
Class-Responsibility-Collaborator
Team Work
Identify classes to build a system
Step 3: Build State Chart
Describe the life-cycle of an object
Many times directly translated into implementation; sometimes not.
Conveys the spec between designer and programmer
Goal: develop overall structure of system
Step 4: Class Design
Interface:
interaction protocol between classes
Operations
Design multiple constructors if necessary
Destructor: very important
Notice virtual destructors
Release system resources
A class can provide 4 categories of ops
Constructor
Accessor
Destructor
Mutator
Purpose: Determine the set of: attributes, operations
Identify: public interface, implementation details of classes
Examine each responsibility
If necessary split class
Start from CRC Cards
Handle Implementation Details
Start from each public operation
Think about how to implement it
Nail down the interface of each class
Outcome: class diagram
Implementation details:
private data members, algorithm of operations
Tools used:
class diagram
CRC cards
interaction diagram
state chart etc.
Process
High level design process
Detailed level design process
Step 2: Construct Interaction Diagram
Process: reconstruct the flow of events using sequence diagram
Mostly used: sequence diagram
4.3: OO Analysis
Two UML tools available
Analysis class diagram
Use case diagram
Step 2: Analysis Class Diagram
Describes: Key class of a system, their relationshi[
Extracts all nouns in the flow of events description
Abstraction of the system
Analysis Class Diagram
Outcome
Initial logic structure of the system
Requirement specification
Step 1: Design of Use Case Diagram
User can be either real human user, or components of a bigger picture
Flow of Events: a sequence of operations for a use case
UCD Must be accompanied by the description of flow of events
Use Case is a way that a user accesses the system
UCD Depicts their relationship
4.5 Design Principles
Principle of Decoupling
Why?
Longer project compiling time
Hard to extend
Hard to maintain
Tight coupling is usually bad
Open-Closed Principle
Open to Extension
he system can be extended to meet new requirements
Close to Modification
The existing implementation should not be modified
How to do it?
Inheritance
polymorphism
Ensuring Cohesion
a class only performs closely related operations
Logically good! Easy to maintain
Chapter1: Introduction to Software Architecture
1.1) Overview
Software systems continue to grow in
Complexity
Scale
Distribution
Why is software architecture design so important?
Poor Design
May result in deficient product
Is not adptive to future requirement change
Not reusable
Exhibits unpredictable behavior or perform badly
Good Design
Make the system traceable for implementation and testing
Help development team works together in an orderly fashtion
Lead to software product that have higher quality attributes
Reduce the risks associated with software production
SDLC
SRS
Result of requirement analysis
Record FUNCTIONAL and NON FUNCTIONAL
Provide input necessary for design
Outcome of software architecture design is SDD. SDD?
Sample base on IEEE 1016
Attributes
User interface description
Dependency and connection description
Decomposition description
Detailed design
Design overview, purpose, scope
Overall representation of the software to be build
The modules that compose each element
Describes the elements of a system
The detail information of each module
What is the architecture design?
Constraints that effect the way in which architecture can be implemented
The Styles and design patterns to achieve the requirements
It design defines the relationship between major structural elements
Two steps in software design
Architectural design
Designer must specify user component and interconnections that are visible to stakeholder
Architecture design is front strategy for the detailed design
Detailed Design/Tactical design
Concerned with local design constraints and the internal detail of each component
Who is responsible for developing the architecture design?
They translate the software system requirements into architecture design
Software architects and designers
They apply various design strategies to divide and conquer the complexities
The goal of software design is to build a model that meets all customer requirements and leads to successful implementation
Any software, should have an overall architecture design that guides its construction and development
1.2 Software architecture: Bridging requirements and implementation
Task of software architects?
IMPORTANT: Map the SRS to the SDD guarantee that functional and nonfunctional requirements are met
Tradeoff analysis on quality attributes
Establish dynamic control relationships among different subsystems
Consider and evaluate alternative architecture styles
Perform static partition and decomposition
Who does the architectural design
Software architect
System analyst
Introduce to Software Architecture
Hightlights early design decisions
Convers functional and non-functional requirement
It is very important in software development
Blueprint guideline for development
Show how system is sturctured
1.4 Quality Attributes
Three catagories
Implementation attributes
Scalability
Can system adapt to increase of requests
Portability
Can be system be deployed on different platforms
Maintainability & Extensibility
The ability to modify the system and conveniently extend it
Flexibility
Ease of modification of system to cater to a different environment
Testability
Whether the system allows easy debugging
Runtime attributes
Usability
Completeness, correctness, compatibility and user friendliness
Performance
Time efficiency and resource efficiency
Availability
Can be enchanced by replication
If system is available 24/7
Security
The ability to defend against attacks
Business attributes
Cost
Expense of the building, maintaining, and operating the system
Lifetime
The period of time that the product is alive before retirement
Time to market
The time it takes from requirement analysis to the product is released
Qualily attributes are identified in requirement analysis process
Quality Attribute Trade-off
Space vs Time
Scalability vs Performance
Reliability vs Performance
Each architeture style has its advantages, disadvantages, and potential risks. So choosing the right style to satisfy required function and quality is very important
1.3 Architectural Styles
Why are architecture styles so important?
Each style has a set of quality attributes that it promotes
By indentify the right style to supports software architecture design we can choose which tectics we can use to better implement the architecture
Why architectural styles
Once overall structure determined, rest are easy
Save cost and time on design
Architecture style represents
What is architecture style?
It contains a set of rules, constraints, and patterns of how to structure a system into a set of element and connectors
Is abstracts the common properties of a family of similar design
It governs runtime interaction of flow control and data transfer
Key components are:
Connectors
that enable communication, coordination, and cooperation among element
Constraints
that define how elements are integrated to form the system
Elements
that perform functions required by a system
Attributes
that describe the advantages and disadvantages of the chosen structure
1.5 Software architecture design guidelines
Guideline 4: Think of reusability and extensibility!
Extensibility is very important
Always try hard to make software extensible in the future.
User requirements can change frequently
Consider how resuse existing software components to increase the reliability and cost-effectiveness of new systems.
Leave the room for expansion
Guideline 1: Think of What to Do before How to Do It.
Notice, different stakeholder have different opinions
Clarify priority of all requirements before design
System requirements must be nailed down before design starts
Guideline 5: High Cohesion and Loose Coupling
The less correlation between modules, the better!
Easy debugging and maintenance
Try to promote high cohesion within each element and loose-coupling between elements.
Design should be logically clear!
Also allows great extensibility
One component (module) should be assigned ONE functionality only
Guideline 3: Think of non-functional requirements early in design process
Balance the quality attributes, and consider heterogeneous architecture styles when necessary
It is not possible to find a design that meets all quality attribute
Speed, Reliability, Security have to be considered first
The earlier, the better
Otherwise, very hard to change your design to reflect these requirement
Guideline 6: Tolerate refinement of design.
We may need to use prototyping and iteration to refine the software design
Never expect to have software design completely perfect within one step
Guideline 7: Avoid ambiguous design and over-detailed design.
Ambiguous design lacks constraints
Over-detailed design restricts implementation.
Guideline 2: Think about abstract design before thinking about concrete design.
Nail down the interface but leave room of change for implementation
Use abstract architectural design to communicate with stakeholders helps avoid overhauling the system design in later stage
Always starts with abstraction
Use multiple level of abstraction if necessary
Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
Chapter 3: Models for Software Architecture
3.3: Structural (Stattic) Diagrams
Class
There are three main different relationships among classes’ these are inheritance, aggregation, and association.They all can be represented graphically in a class diagram.
Describe each individual class with its type, interface, properties, and methods.
One important part of a class diagram is the interface of each class
Popular accessibility modifiers include private, public, protected, and default
Is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle.
Provides a static view of the system. It captures the vocabulary of the designed system.
Is the foundation diagram of the system design and it is the most frequently used UML diagram as well.
For each relationship, multiplicities between classes can be denoted. Typical multiplicity types include one to one, one to many, and many to many mappings.
Component
UML 2.0 introduced a new notation for components and connections between components.
A cup shape represents the required interface, and the required interface must be provided by some other components.
Each component has an interface to expose its services and hides its implementations.
Is a deployable reusable building block for software design and development.
The interface is the contract between reusable component and its clients.
Is neither a class nor an object.
Composite Structure
There are two basic notations in a composite structure diagram
Collaboration (represented using a dashed eclipse)
Structured class (represented using a rectangle box)
Each structure class may have an annotation which indicates its “role” in the collaboration.
Is used to describe the composition of interconnected elements or the collaboration of runtime instances.
Object
Shows a snapshot of class instance connection and interaction.
Is used to describe a sample subset of objects in the system at a point of time.
Many other behavioral diagrams (sequence diagram, communication diagram, and interaction diagram) can make references to the object diagram.
Deployment
Is generated in the later phase of software development life cycle.
UML uses a cube symbol to represent a computing resource node; such a resource can be a hardware device or a deployed software subsystem.
Depict the physical configuration of the software system deployed on hardware server nodes and the network between the nodes (defined as protocols).
All components in the system need to be deployed on servers to provide services via network protocols.
Component diagrams are the basis for the deployment diagram.
Package
Is represented by a tabbed folder that indicates where all included classes and sub packages reside.
The use of package diagrams to represent system structure can help reduce the dependency complexity and simplify relationships between groups of classes.
Shows the dependency relationship between packages (see static structure above), where a change of one package may result in changes of other package due to this dependency.
May also specify the contents of a package, i.e., the classes which constitute a package and their relationship.
Packages play a similar role as a directory for grouping files in a file system; they allow the organization of all closely related classes in a well-formed manner to be placed in one “container.”
We can also organize related packages in a same parent package to build a class and package hierarchy just like.NET class library and Java API.
3.1: Overview
There are five views in the model
The process view
Addresses non-functional requirements such as module communication styles and performance issues at runtime.
The user interface view
The development view
Organizes the software units in well-defined ways according to the actual file or directory structure.
The physical view
Specifies the deployment infrastructure in terms of software, hardware, and networking configurations, installation, and deployment for delivery purposes.
The logical view
Is used to identify software modules and their boundaries, interfaces, external environment, usage scenarios, etc.
Box-and-line diagrams will be used throughout this book for specification purposes
Every software architecture must describe the collection of software components and the connections and interactions between these components.
There are many effective ways to describe the software architecture formally or informally
Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle
Software architecture specifies a high-level of abstraction of a software system by employing decomposition, composition, architectural styles, and quality attributes.
The “4+1” view model is another way to show different views of the functional and non-functional requirements of the software project
It must also specify the deployment configuration of all components and connections.
3.2: UML for Software Architecture
Provides several modeling diagrams that can be grouped into two major categories: Structural (static) and Behavioral (dynamic).
Is a typical OO analysis and design notational tool that provides many useful diagrams that can be used to map requirement specifications to architectural designs and from these to coding.
The related UML diagrams are sequence diagram, collaboration diagram, activity diagram, etc.
3.4: Behavioral (Dynamic) Diagrams
Use Case Diagram
It consists of actors, use cases and links between them.
Are scenario-oriented in the sense that each is a sequence of working steps to be carried out by classes in order to provide the required system functionality.
Describe user requirements in terms of system functionality (use cases) as a contract between the user (actors) and the software system.
An <<extend>> link
Is also a dashed directed line with an arrow towards the extended use case; these special links are labeled accordingly.
It covers alternative cases that may or may not necessarily take place.
Shows a newly created optional use case from an existing use case.
An <<include>> link
Is a dashed line with an arrow pointing to the reused use case
A special kind of link, from one use case to another indicates that the first use case reuses or includes the latter use case and it is needed to complete the work to fulfill the requirement.
The (simple) connection link from actor to use case shows the direction of actors using the use case.
An actor in a use case diagram is an external “user;” this may be a human end user, an application, an external device, or another system.
Each use case is a meaningful operational work scenario.
State Machine Diagram
Is a situation in which an object meets conditions, takes actions, and waits for new event. When a new event takes place in the current state, the machine will perform specified actions and then will enter a new state (the next state).
Each state machine diagram has one starting point in a solid black circle and has one or more endpoints, the latter indicated by eye-circles.
In a state machine diagram, a state is a rounded rectangle with three subdivisions
State variables
State name
State activities
Called state charts in UML 1.x, are widely used for embedded systems and device software analysis and design.
Is an event-oriented diagram where the software elements in the system change their states in response to external or internal stimuli (such as time events or other system events).
Are ideal for specifying the internal behavior of objects.
Communication or Collaboration Diagram
Known as collaboration diagram in UML 1.x, is a message-oriented diagram that describes ALL message passing sequence, flow control, object coordination, etc, between the objects that participate in certain use case.
Is an extension of the static object diagram where the links between objects represent the association relationships.
Above the links in a communication diagram are the numbered messages, indicating the order in which they are sent or received.
These two type of diagrams provide a message-oriented and time-oriented view, respectively.
Summarizes how objects in the system receive and send messages from/to other objects.
Interaction Overview Diagram
Is a variant of the Activity Diagram.
The nodes in a Interaction Overview Diagram represent either interactions reference to some existing diagrams (ref) or interaction basic element (activity diagram (ad) or sequence diagram (sd)).
Each node (called frames) can be any interaction diagram
A reference node, indicated by a “ref” in the up-left corner of frame, points to an existing diagram while the basic element directly displays the dynamic interaction diagram in it.
Describes the control flow of the interactions rather than message.
Activity Diagram
UML activity diagrams use a rounded rectangle to represent an activity.
Also support communication between two concurrent flows by sending signals from one path to another (this is called an event and it is noted as a pair of convex polygons).
One activity diagram corresponds to one business process. There are many activities in a business process.
Is used to describe complex business processes
Is a workflow-oriented diagram describing steps on a single process.
A small diamond represents a decision point in the diagram.
Also support parallel processing using a pair of black horizontal bars to indicate the corresponding fork/join actions in such pathways.
Each activity diagram starts with a starting point and finishes with one or more finishing points.
Sequence Diagram
Each participant object in this diagram has a vertical timeline for its life cycle.
Each activation box may also have a self-recursive directed link pointed back to itself, indicating the object passes messages to itself.
An activation may also branch or fork many separate lifelines for the if-selection scenario conditions; eventually all forked lines will join together.
Time goes forward along with the timeline downward.
Each vertical timeline has a number of narrow rectangle boxes (called activations) representing the object activated state where either it receives messages or sends out messages.
A message passing action between objects is represented by a horizontal arrow link from the source to the destination. It is represented by a solid line with an arrowhead.
An object can send a synchronous message to another object by a synchronous message line with a full arrowhead.
A synchronous message means that the sender must wait for the reply from the target object before it can move forward in their timeline.
Is a time-oriented interaction diagram showing the chronological sequence of messages between objects.
is one of the most important and most widely used UML diagrams for software system analysis and design.
Usually, one sequence diagram corresponds to one use case.
Timing Diagram
Is a new diagram in UML 2.0.
Combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time.
Is often used in time-critical systems such as real time operating system, embedded system design, etc.
3.5: Architecture View Models
The model provides four essential views
The Physical View
The stakeholders of this view are system installers, system administrators, system engineers, and operators.
A physical view also takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), throughput performance, scalability performance, and security.
Describes installation, configuration, and deployment of the software application.
Is particularly of interest in distributed or parallel systems
It concerns itself with how to deliver the deployable system.
Shows the mapping of software onto hardware.
The Logical or Conceptual View
It is typically used for object-oriented modeling from where the static and dynamic system structures emerge.
The view basically is an abstraction of the system's functional requirements.
The logical view specifies system decomposition into conceptual entities (such as objects), and connection between them (such as associations).
Is based on application domain entities necessary to implement the functional requirements.
The logical view is typically supported by UML static diagrams such as: class/object diagram and UML dynamic diagrams such as interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
It focuses on functional requirements and the main building blocks and key abstractions decomposing of the system.
The Process View
Focuses on the dynamic aspects of the system, i.e., its execution time behavior.
Is a runtime execution unit.
The quality attributes such as performance, scalability, concurrency, synchronization, distribution, and system throughput are addressed here.
The non-functional requirements are also important issues the process view must address such as multi-threading, synchronous and asynchronous communications for performance and availability.
Many architectural styles such as pipe & filter, multi-tier, and others can be applied in the process view
Is a coordination view of the system's processes and the communications between them.
The UML activity diagrams and interaction overview diagram support this view.
It contributes to many non-functional requirements and quality attributes such as scalability and performance requirements.
Takes care of the concurrency and synchronization issues between sub-systems in the system.
Is an abstraction of processes or threads dealing with process synchronization and concurrency.
Is also derived from logical view.
A software system can be decomposed into many such units.
The Development or Module View
It is derived from the logical view.
Modules such as namespaces, class library, sub-system, or packages are building blocks that group classes for further development and implementation.
Each package has its own visibility and accessibility as package or default scope visibility (see static structure discussion above).
UML diagrams such as package diagrams and component diagrams are often used to support this view.
The development view maps software component elements to actual physical directories, files in the development environment.
In this view, the software is packaged and partitioned into small units such as program libraries or sub-systems that are developed by many teams of developers
Describes the software static organization of the system modules.
Addresses the sub-system decomposition and organizational issue.
The scenario view
Describes the functionality of the system, i.e., how user will use the system and how the system provides services to the users.
Helps to make the software architecture consistent and validated against functional and non-functional requirements.
It helps designers discover architectural elements during design and helps to validate the architectural design afterward.
This view provides a foundation for other 4 views and lets them work together seamlessly and coherently.
The User Interface View
Any modification on this view will have direct impact on the scenarios view.
May be provided as a series of screen snapshots or a dynamic, interactive prototype demo.
Giving user-computer clear interface view while hiding implementation details.
Specific views models provide partial representations of the software architecture to a specific stakeholder such as system users, the analyst/designer, the developer/programmer, the system integrator, the system engineer, etc.
Software designers can organize the description of their architectural decisions in different views.
There is no single view that can present all aspects of complex software to stakeholders.
The 4+1 view model standardizes the software design documents and makes it easy to understand by all stakeholders.
A model is a complete, simplified description of a system from a particular perspective or viewpoint.
The 4+1 view model is a multiple-view model that addresses different aspects and concerns of the system.
The scenario view is coherent with other four views, whereas the user interface view complies with the scenario view and is supported by the other four views.
Chapter 2 : Software Architecture Design Space
Design space
design alternatives that can support functional and
non-functional requirement specifications
Types of Software Structures
Management Structure
Can be used for resource allocation
Static Structure
A software project is typically implemented in multiple files
Static connectors may exhibit some attributes
Sequence
Synchronization
Direction
The connectors at this level are in the form of module dependency
Runtime Structure
Run-time Connector Properties
inherit attributes from their source-code structure counterparts, with a few extra attributes
Self-descriptive
allows clients to choose service providers dynamically
Distance and connection media
Two connected element may communicate in the same thread, in the same process , on the same computers, or on different computers across a network
Multiplicity
One element can be connected to multiple elements
Universal invocable
irrespective of hardware/software platform, and programming languages
Software Runtime Element
same element in a code structure can implement or support multiple runtime elements
several code structure elements may implement or support a single runtime element
A runtime project consists of elements
Processes
Distributed objects
Threads
Web services
Software Element
At runtime, element is a self-contained component of a system
Some example : Functions and procedures in C, System utility programs in UNIX, Web Services, Distributed Objects
Software Architects Job
Map functional requirements to software elements
Rule 2: Handle Bottle-Neck First
Treat bottle-neck functionality using approaches
Improving its efficiency by replication
allocate cluster or multi-CPU computers for bottle-neck modules in deployment
Wrap it as a separate and highly independent module
Rule 3: Make Things Simple
Split it into smaller ones
Horizontal Layers
Vertical Layers
Rule 1: Reentrant
describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users
making sure that no instruction modify the contents of variable values in other instructions within the program
it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing
Software Connector
determines the quality attributes of a system
Security
Reliability
Availability
Efficiency
Connector type
initiator
One Initiator
only allows one of the two connected elements initiates the request
Two Initiator
either of the two elements can make the request
Non-blocking
allows one of its incident elements to send a request to another and continues its execution without waiting for a response
Blocking
allows one of its incident elements to send a request to another and wait for a response
the element will be blocked from further execution until it receives a response
Implementation type
Protocol based
A protocol-based connector can implement multiple operation types with a single binding signature
Signature based
Method parameter indicates operation type
Usually method invocation
refined within the design process
Connects the modules of a system
Chapter 8: Implicit Asynchronous Communication Software Architecture
Applicable Domain of Message-Based Architecture
Limitations
Increased complexity of the system design and implementation
Difficult to determine the numbers of agents needed to satisfy the loose couplings between agents
The event handler must be ready in order to be able to intercept an event
Commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture
Capacity limit of message queue
A message receiver can still receive messages even if it is not running at the time the message was sent
Generate development complexity since communications between agents only take place between the control of agents
Benefits
Supporting for concurrency among consumers
Supporting batch processing
Providing high degree of anonymity between message producer and consumer
The message consumer does not know who produced the message
Providing scalability and reliability of message delivery
Supporting loose coupling between message producers and consumers
Nonbuffered Event-Based Implicit Invocations
Related architecture
PAC, message-based, MVC, multi-tier, and state machine architectures
Benefits
Framework availability
Reusability of components
System maintenance and evolution
Independency and flexible connectivity
Parallel execution of event handlings is possible
Limitations
It is difficult to test and debug
Reliability and overhead of indirect invocations may be an issue
tighter coupling between event sources
Applicable domains
Interactive GUI component communication
Require loose coupling between components
When event handlings in the application are not predictable
Implementation of state machines
Buffered Message-Based Software Architecture
breaks the software system into three partitions:
Message producers
Message service providers
Message consumers
They are connected asynchronously by either a
message topic: one-to-many
message queue : one-to-one
Publish-Subscribe Messaging (P&S)
Point-to-Point Messaging (P2P)
Chapter 5:Data Flow Architecture
5.3)Pipe & Filter
Summanry
Data format on the data stream is simple and stable, and easy to be adapted if it is necessary
System can be broken into a series of processing steps over data stream, in each step filter consumes and moves data incrementally
There are significant work which can be pipelined to gain the performance
Suitable for producer/ consumer model
Classification of filters
Passive filter
The filter must provide read/write mechanisms in this case
Lets connected pipe to push data in and pull data out
Active filter
Its works with a passive pipe that provides read/write mechanisms for pulling and pushing
EX: UNIX pipe
Pull in data and push out the transfromed data(pull/push)
Basics Concepts
Pipe: data conduit
Two types: charater of byte streams
Moves data from one filter to another
Filter: independent data steam tranformer
Does not wait for batched data as a whole
Does not even have to know identity of i/o streams
Reads data from input data stream
Process data and write to output stream
Data Source
Data Sink
Advantages
Simplicity: clear
Modifiability: Low due to coupling between filters
Reusability is easy - plug and play
Concurrency in high
Lower latency
Flexibility: high, very modular design
Disadvantages
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
Data standards (ASCII, XML?)
Not suitable for dynamic interactions
Difficult to configure a P&F system dynamically
Error handling issue
In Java
Can work in parallel manner
Java.io provides pipedwriter and pipedreader
Three way to make data flow
Push only (Write only)
A data source may push data in a downstream
A filter may push data in a downstream
Pull only (Read only)
Filter may pull data from an upstream
A data sink may pull data from an upstream
Pull/Push (Read/Write)
A filter may pull data from an upstream and push tranformed data in a downstream
In Unix
Unix provides pipe operation "|"
Moves stdout from predecessor to the stdin of its successor
Similar to batch sequence
Independent modules
Data connections
Difference
Connections are stream oriented
Concurrent processing
5.2)Batch Sequential
How to implement Batch Sequential
DOS batch file
Direct implementation in coding
Usually done in batch processing language of shell script
Widely used in 1950s -1970s
Limitation
No concurrency and low throughtput
High latency
No interactive interface
Traditional data processing model
Benefits
Simple division between sub-system
Each sub-system can be a stand-alone
Applicable design domains
Data are batched
5.1)Overview
What is data flow architecture?
No Inreraction between modules
Connection can be
Filesm, Buffers, Pipes
IO Steam
Modules do not need to know identify of each other
Whole system as transformation of successive sets of data.
System decomposed into modules
Categories of data flow arch
Many sub-categories exist
Batch sequential
Pipe & Filter
Process Control
To adopt which one depends on the nature of the problem
5.4) Process Control Model
Applicable Domains
Embedded software system involving continuing actions
Needs to maintain an output data at a stable level
The system has a set point which is the goal the system will reach and stay at that level
Composed of
Connection
sub system
Suitable for embedded system
Two type of sub-system
Controller unit
Executor processor unit
Pros and Cons
Limitations
Requires more sensors to monitor system states
Benefits
Better for situations where no precise formula for deciding the manimulated variable
Can be completele embedded
Data
Input variable: measured input data
Manipulated variable: can be ajusted by the controller
Controlled variable: target controlled variable
System depends on: Control variable
Chapter 7: Hierarchical Architecture
Main/subroutine:
Main/Subroutine Design
Objective: Map from DFD to Main/Subroutine Design
Usually Requirement Spec. Specified in Data Flow Diagram (DFD)
DFD
Two types of flow
Transform Flow:
input data get processed and results in output data (sequential)
Transaction Flow:
depending on input data, take different control actions (branch)
Idea: System decomposed into sub-routines
Mapping Process
Generally: a main process controls the overall flow
Map each flow into a subroutine
Identify transform and transaction flows
Summary
Limitation:
Globally shared data are vulnerable
Tight coupling may cause ripple impacts as compared to OO design
Benefits:
Easy to decompose the system
Can still be used in sub-system of OO Design.
Probably the oldest and most widely used architecture.
Purpose: Encourage re-use of modules
Virtual Machine
Limitations:
Additional overhead due to the new layer
Slow execution of the interpreter
Applicable Design Domain:
Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language
Suitable for solving a problem by simulation or translation
Idea:
Provide a virtual interpretation layer that separates
Application
Physical machine layer
Benefits:
Simulation for non-native and disaster working model
Simplicity of the software development
Portability and machine platform independency
Variation of Layered Approach
General Rules
Plus Point:
Any changes to a specific layer may affect only its adjacent upper layers.
So, no ripple effects of change
Services at lower level provides more specific functionality down to fundamental utility services such as I/O services, transaction, scheduling, security services, etc.
Middle layers provide more domain dependent functions such as Business logic, core processing, etc.
Upper layers provide more abstract functionality in the form of user interfaces such as Command line interpreter, GUI, Shell programming
Layered Arch
Physical Implementation
Functions in one layer usually organized in one package
Limitations:
Lower runtime performance
Many applications can not fit this architecture
Exception and error handling
Idea:
functionality grouped into layers
upper layer invokes func. in lower layer
Applicable Design Domains:
For systems that can be divided between portions providing generic services to the application of the system
For applications which have classes that are close related each other
Benefits
Enhanced independence of upper layer to lower layer
Promotion of portability
Incremental software development
Enhanced reusability and interchangeability
Component-based technology is a suitable
Master-Slave
In this architecture:
Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
The slaves provide replicated services to the master
The master selects a particular result among slaves by certain selection strategies.
It supports Fault tolerance and system reliability
A variant of main-subroutine architecture
Characteristics: Parallel computing and accuracy of computation
Applicable domain: Where reliability is crucial
Related implementation techniques
Chapter 6: Data-Centered Software Architecture
Blabkboard
Cons :red_cross:
Tight dependency between the blackboard and knowledge source
Debugging and testing of the system is a challenge
Synchronization of multiple agents is an issue
Properties
They don’t need to interact with each other
Each knowledge source is relatively independent
Only interact and respond to the blackboard subsystem
Pros :check:
Scalability: easy to add new knowledge source
Concurrency: all knowledge sources can work in parallel
Reusability of knowledge source agents
Consists of three partitions
Knowledge Source : stores domain specific knowledge
controller :initiating the blackboard and knowledge sources
Blackboard :Used to store data
Clients are inactive/passive
How does it work :question:
Data driven – a change in the data stored in Blackboard triggers one or more knowledge source
Application Domain
Suitable for solving immature and complex AI problems
Optimal, partial, or approximate solution is acceptable
The problem spans multiple disciplines, each of which has complete different knowledge expertise
Exhausted searching is impossible
Flow of logic is determined by the current data status
Listeners or subscribers
Knowledge sources
Data store is active
Repository
Cons :red_cross:
High dependency between data structure of data store
Overhead cost of moving data on network
Data store reliability and availability
Other issues - concerns
Collaboration (two-phase transaction commitment)
Vertical or horizontal partitions
Synchronization of duplicated data
Cost of data transmission
Variants of Data Repository
Distributed repository system
Data are replicated in order to
All data are distributed over all sites linked by network
Virtual repository
Benefits
Security management in terms of scope of data of manipulation for different users
Simplify the overall complexity of overall database structure
Benefits
:check:
System scalability and Reusability of agents :Reduce the overhead of transient data between software components
Data integrity : easy to backup and restore
Application Domain
Data transactions drive the control flow
Suitable for large complex information system
Data store is passive
Clients of the data store are active
Chapter 10: Distributed Architecture
Introduction
Definition of Distributed System
Is a collection of computational and storage devices connected through a communications network.
Components are distributed.
Two importants issues
Topology: the way components connected.
Mode: the method they communicate with each other.
Models
Multi-tier
Overview
Middle-end tier - Business logic tier
Back-end tier - DB management tier
Front-end tier - User interface presentation tier
Pros and Cons
Pros
Middle layer is easy to change
Have portable and non proprietary design and implementation
Middle layer can provide multi-threading support
Reduces traffic on the network
Cons
Difficulty in testing due to lack of testing tools
Adding multiple servers in the system makes the server reliability and availability even more critical
Broker
Overview
Transparently distribute aspects of the software system to different nodes
Skeleton (server-side proxy) – encapsulates lower network details, dispatch requests to local service objects
Bridges (optional) – for interaction with brokers
Stub (client-side proxy) – provide “stub” version of remote services, responsible for massaging messages
Network – for interaction with brokers
Broker – provide service registration
Key Idea
Clients discover services through broker
Clients submit requests to broker
Service provider register services through broker
Broker massages requests from clients and relay results from service provider
Typical Example:CORBA, RPC, and RMI
Pros and Cons
Pros
Changeability and extensibility,
Feasibility of run time changes of server components (add or remove server components)
Server component implementation and location transparency,
Cons
Low fault tolerance
Difficulty testing
Inefficiency due to the overhead of proxies
Client/Server
Overview
The most commonly distributed system architecture
It has two communicating processes
Client: Running on different processors.
Server: Server process receives the request, carries it out, and sends a reply to the client.
Pros and Cons
Pros
Responsibility separation such as user interface presentation and business logic processing .
Reusability of server components
Cons
Lack of heterogeneous infrastructure to deal with the requirement changes.
Security complications
Server availability and reliability
Testability and scalability
Service Oriented
Overview
A Service Oriented Architecture (SOA) starts with a businesses process.
A service is a business functionality that is well-defined, self-contained, independent from other services, and published and available to be used via a standard programming interface.
Software manages business processes through a SOA with well-defined and standard interfaces that can build, enhance, and expand their existing infrastructure more flexible.
SOA services can be extensively reused within a given domain or product line, and even among legacy systems.
Loose coupling of service–orientation provide great flexibility for enterprises to make use of all available service recourses regardless of platform and technology restrictions.
The connections between services are conducted by common and universal message oriented protocols such as the SOAP Web service protocol, which can deliver requests and responses between services loosely.
A connection can be established statically or dynamically.
Advantages of SOA
Interoperability: Technically any client or any service can access other services regardless of their platform, technology, vendors, or language implementations.
Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier.
It makes SOA software much easier to evolve and update.
SOA based business application development comes much more efficient in term of time and cost.
The implementation of a service will not affect the application of the service as long as the exposed interface is not changed.
Scalability: Loosely coupled services make themselves easy to scale.
Each service component is independent from other services due to the stateless service feature.
The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute.
Loosely-coupled connection: Loose-coupling is the key attribute of SOA.
Chapter 9: Interaction Oriented Architecture
Interactaction Oriented SW architecture
More and more SW involve user input/output interaction, so specific user interfaces to software design.
Interaction oriented SW architecture decomposes the system into
Data module
-Provides data abstraction
-All core business logic on data processing
Control module
-Flow of control of view presentation
-Communication between modules
-Job dispatching
-Certain data initialization
-System configuration
View presentation module
-Visual or audio data output presentation
-Provide user interface when necessary
Key points:
-Separation of user interactions from data abstraction and business logic.
-This is because:
Many view presentation in different data formats
Multiple views is supported for the same data set.
Even for a specific view presentation, the view or interface may need to change so often, so the loose coupling between data abstraction and its presentation is helpful. This is supported in this style.
Overview
-Software has to interact with people
-From 1950’s, existing human-computer-interaction:
Punched Cards (1950’s)
Teletype Terminal (1970’s)
Personal Computer + Keyboard (1970’s)
Color Monitor + Mouse + GUI (1980’s)
Multimedia + Speech Recognition (1990’s)
Motivation
Software grows more complex when richer user interaction is required
Many problems! Examples?
-Update of user view however business logic is not changed
-Validating user input:
+buffer overflow
+SQL injection attack
Two Major Categories
Presentation-Abstraction-Control (PAC)
PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements.
Key Idea
PAC: hierarchy structure for interacting or cooperating agents
Each agent has three components
Presentation
Abstraction
Control
Each agent responsible for one function
Sometimes all agents share the same control
Provides interaction between agents
Within each agent there are no direct connections between the abstraction component and presentation component
Usage
PAC is suitable for distributed systems where all agents are distantly distributed and each agent has its own functionalities with data and interactive interfaces.
Sometimes, middle level agents, the interactive presentations are not required.
Example
Desktop Presentation Application that can browse and display presentation pages in a graphical one at a time.
Has 4 buttons:
-First page
-Last page
-Next page
-Previous page
Summary - PAC
Applicable domain of PAC architecture:
Suitable for where there are many cooperating agents in a hierarchical structure.
The coupling among the agents is expected very loose
Benefits:
Supporting multi-tasking, multi-viewing
Supporting agent reusability and extensibility
Easy to plug in new agent or replace an existing agent
Supporting concurrency
Limitations:
Overhead due to the control bridge.
Difficult to design agents
Model View Controller (MVC)
MVC
Widely used in web applications
E.g., MS ASP.Net, Java Swing
First introduced in 1980’s SmallTalk
Key Idea
Model: model of application’s logic
View: deal with graphic representation
Controller: contains the interface between model and view
Note: model does not (and should not) know view and controller. It should not depend on the other two components.
Concept for model:
The Model manages the behavior and data of the application domain.
The model responds to requests for information about its state (usually from the view), and
responds to instructions to change state (usually from the controller).
Concept for View:
The View renders the model into a form suitable for interaction, typically a user interface element.
Multiple views can exist for a single model for different purposes.
A view port typically has a one to one correspondence with a display surface and knows how to render to it.
Concept for Controller:
The Controller receives user input and initiates a response by making calls on model objects.
A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
MVC-I
Simplified System
Controller/View
Model
Controller/View
Takes care of input/output, interface to model
Model
In charge of business logic
Summary MVC
Applicable domain
Suitable for where multiple views needed for a single data model and the graphics interfaces prone to data changes.
There are clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications.
Benefits:
Easy to plug in new or change interface views,
Very effective for developments (team working by different professionals)
Limitations:
Does not fit agent-oriented application such as robotics applications
Multiple pairs of controllers and views make data model change expensive
The division between the View and the Controller is not very clear in some cases
Difference of MVC and PAC
They differ in their flow of control and organization.
PAC is an agent based hierarchical architecture, whereas MVC does not have any clear hierarchical architecture. All three modules are connected together.
Chapter 11: Component Based Architecture
Introdution notions of Software Component
Component Base Architect
Each sub-problem is associated with a component
interface play an important role
Divide a problem into sub-problems
Motivation
A component encapsulates the functionality and behavior of a software element into reuseable and self -deployable binary
Component are highly reuseable
Use of COTS or developed in-hourse component
increase overall reliability
Can greatly reduce development cost
Component
It may require services from other components
It remains self-contained and substitutable as long as it interface is unchanged.
A component is a deployable software package that can provide services to its client
Components Vs. OO design
In component-oriented design
First identify all components and their interfaces
Advantages over CO design
Lower development costs by reuse of the existing components, and
increased reliability with reuse of the existing components
Reduced time in market
A component-oriented represents a higher level of abstraction than an equivalent OO design
The component-oriented design defines components and connections between them instead of classes and connections between classes
Definition
A component is a modular (cohesive), deployable (portable), replaceable (plug-and –play), and reusable set of well-defined functionalities that encapsulates its implementation and exports it as a higher-level interface.
Why use ?
Composability
Adaptibility
Productivity
Scalability
Reusability
Reliability and many others
Principles of Component-Based Architecture
Figure out semantics of connections
Communication semantics important
Think about INTERFACE, not the implementation
Component Level Design
A collaboration diagram
the implementation of a use case
For each use case U, there will be a collaboration diagram “encapsulated” in a component C.
is an identifiable slice of functionality that describes a meaningful service involving several concepts.
Business concept diagram
Extract business process entities that can exist independently without any associated dependency on other entities.
Recognize and discover these independent entities as new components.
Depicts the relationships of the business process entities in the domain
Use case diagrams
We can map use case diagram to the provided service interfaces of the first-cut component specification'
Describes user interactions with the system which indicate all necessary operations of the component
Starts from Use Case Diagram
May also need business concept diagram
Before the design phase
Use case modeling
Business concept modeling
Mapping
conceptual classes => modules of components
If necessary, big components can be further decomposed
Use case => interface provider
Pros and Cons
Pros
System maintenance and evolution:
Independency and flexible connectivity of components
Reusability of components:
Many OO design tools available
Productivity
Cons
Sometime it is difficult to find suitable components to reuse.
Adaptation of components is always an issue.