Please enable JavaScript.
Coggle requires JavaScript to display documents.
INTRODUCTION TO SOFTWARE ARCHITECTURE - Coggle Diagram
INTRODUCTION TO SOFTWARE ARCHITECTURE
Chapter 1
1.1 Overview
Goal of Software Design
is to build a modal that meet all customer requirement and lead to successful implementation
What is architectural Design
It also define the style of design pattern used to achieve requirement
Also the constraint that effect the way architecture can be implements
It define the relationship between major structural elements
Who is responsible for develop structure design ? ===> Software architect and designer
They apply various design strategies to divide and conquer the complexities.
They map Software Requirement into Architecture design
The architecture of system is it's skeleton. It is a highest level of a system.
Software architecture is more about the design of the entire system, while software design emphasizes on module/component/class level.
Why SW architecture design is important ?
Poor Design
May result deficient product
Is not adaptive to future requirement changes
Not Reusable
Good Design
Reduce risk associate with SW production
Helps development team works together in an orderly fashion
makes the system traceable for implementation and testing, and leads to software products that have higher quality attributes
Software Development Life Circle (SDLC)
Design (architecture and detail) ==> SDD
Implementation
Specification Analysis ==> SRS
Testing and maintenance
SRS
Functional Requirement
Serve as contract between Developer and customer
Non-Functional Requirement
System constraint and pre-condition
Software Design Description (SDD)
Component of the systemt
Module of each Component
Detail information of each module
Operation
Data attribtute
Developer
Software Design Description (SDD): an overall representation of the software to be build.
2 Step In Software Design
Architectural Design
Describe user accessible components and the interconnection among them that are visible to stackholder
Detail / Tactical Design
Specify the internal detail of each component to stack holder, into design
Architectural Design is font strategy for detail Design
1.2 Software Architecture: Bridging requirement and implementation
Software Arch: very important in software development
Highlights early design decisions
Shows how system is structured
Covers functional and non-functional requirements
Blueprint guideline for development
Software Architect
Establishing dynamic control between subsystems
Considering and evaluating all alternative architectural styles
System static partition and decomposition
Analysis of trade-off on quality attributes
1.3 Architecture Style
What is Architecture Style ?
An architecture style (also known as an "architecture pattern") abstracts the common properties of a family of similar designs.
It contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
It governs runtime interaction of flow control and data transfer
Key Component
Connectors that enable communication, coordination, and cooperation among elements
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
How to decide archirecture style
Each architecture style has its advantages, disadvantages, and potential risks. Choosing the right style to satisfy required functions and quality attributes is very important.
Quality attributes are identified in the requirement analysis process.
Depends on how quality attributes are satisfied
Why Architecture Style
Architecture style represent
Once overall structure determined, rest are easy
Save time & cost on design
1.4 Quality Attribute
Run-time Attribute
Security
Performance
Availability
Usability
Business Attribute
Cost
Lifetime
Time to market
Implementation Attribute
Testability
Portability
Maintainability & Extensibility
Scalability
Interoperability
Universal accessibility and ability to exchange data among internal components and the outside world
Fexibility
Many quality conflict to each other
Reliability & Performance
Scalability vs Performance
Space and time
1.5 Software Architecture Design Guidline
Guideline 3: Think of non-functional requirements early in design process
Speed, Reliability, Security have to be considered first
Otherwise, very hard to change your design to reflect these requirements
The earlier the better
t is not possible to find a design that meets all quality attributes.
Balance the quality attributes, and consider heterogeneous architecture styles when necessary
Guideline 4: Think of reusability and extensibility!
User requirement can change frequency
Extensibility is very important
Leave room for expansion
we need to consider how to reuse existing software components to increase the reliability and cost-effectiveness of new systems
Always try hard to make SW extensible in the future
Guideline 2: Think about abstract design before thinking about concrete design
Always start with abtraction
Use multiple abstraction level if nessesary
Nail down the interface but leave room of change for implementation
Using an abstract architectural design of a system to communicate with stakeholders helps avoid overhauling the system design in later stages of the software development cycle.
Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
Guideline 5: High Cohesion and Loose Coupling
Try to promote high cohesion within each element and loose-coupling between elements.
One component (module) should be assigned ONE functionality only
Design should be logically clear
The less correlation between modules, the better!
Easy to debug and maintainance
Also allows great extensibility
Guideline 1: Think of What to Do before How to Do It.
System requirements (functional and non-functional requirements) must be nailed down before design starts
Clarify priority of all requirements before design
Guideline 6: Tolerate refinement of design.
Never expect to have software design completely perfect within one step.
We may need to use prototyping and iteration to refine the software design
Guideline 7: Avoid ambiguous design and over-detailed design.
Ambiguous design lack constraints
Over-detailed design restricts implementation
Chapter 4
4 Principles of OOP
Encapsulation
Encapsulation is the mechanism of hiding of data implementation by restricting access to public methods. Instance variables are kept private and accessor methods are made public to achieve this.
For example, we are hiding the name and dob attributes of person class in the below code snippet.
Abstraction
Another real-life example of abstraction?
Think about how you use your phone:
You interact with your phone by using only a few buttons. What’s going on under the hood? You don’t have to know — implementation details are hidden. You only need to know a short set of actions.
Abstract means a concept or an Idea which is not associated with any particular instance. Using abstract class/Interface we express the intent of the class rather than the actual implementation. In a way, one class should not know the inner details of another in order to use it, just knowing the interfaces should be good enough.
Polymorphism
Take a look at a sketch of geometric figures implementation. They reuse a common interface for calculating surface area and perimeter:
If you have a function which operates with a figure by using its parameter, you don’t have to define it three times — once for a triangle, a circle, and a rectangle.
It means one name many forms. It is further of two types — static and dynamic. Static polymorphism is achieved using method overloading and dynamic polymorphism using method overriding. It is closely related to inheritance. We can write a code that works on the superclass, and it will work with any subclass type as well.
Inheritance
Inheritances expresses “is-a” and/or “has-a” relationship between two objects. Using Inheritance, In derived classes we can reuse the code of existing super classes. In Java, concept of “is-a” is based on class inheritance (using extends) or interface implementation (using implements).
For example, FileInputStream "is-a" InputStream that reads from a file.
Chapter 2: Software Architecture Design Space
Architecture Design Space
A software architect's responsibility
Proposing a concrete architecture that best support the details design and implementation of a specific project
Software architecture must understand the SW Architecture's design space
Design alternative that can support functional and non-functional requirement specifications
Design Space
What are popular building elements?
What are popular connectors?
What are popular structures?
Based on quality Attribute
Type of software structure
Software Runtime Structure
Consist of these Element
Threads
WebServices
Processes
Distribute Object
Software runtime structure serve as technical backbone of architecture design and provide a basic from which other structure are derived
Software Runtime Element
The 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
Runtime Connector Properties
Runtime connectors inherit attributes from their source-code structure counterparts, with a few extra attributes
Multiplicity
One element can be connected to multiple elements if it needs to invoke methods of multiple elements at runtime.
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
Universal Invokable
A connector with this attribute set to true allows any external software system to invoke the methods at the connector’s target, irrespective of hardware/software platform, and programming languages
Importance to heterogeneous system
seft-description
A connector with this attribute set to true allows any external software system to invoke its target method without pre-installation of any software specific to the method.
it allows clients to choose service providers dynamically.
These elements may run on the same computer or on multiple computers across a network.
Software Static Structure
A software project typically implement in multiple files.
Binary software component modules
Deployment Description
Library files
Others Resource Files
Executable files
Static Connector may exhibit some attribute
Direction
Synchronization
Sequence
At SW deploy time
The main software elements are source code files
Each modules has assigned functional and nonfunctional attributes
API defined for modules separates module’s interface and implementation
The connectors at this level are in the form of module dependency
Module A is connected to module B, if, A needs to invoke some methods in B during execution.
Managing Static Structural Representations
The SW static Structure
refers to the organization of physical software modules and their interrelations
This structure play a critical roles in software architecture design
Static structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability…
It plays a crucial role in the management of large software systems because it deals with the packaging of software modules in order to facilitate system construction and maintenance through a clear portrayal of intermodule relations.
Managing static structures involves layers of:
Abstraction for encapsulation
Refinement showing visibility
two kinds of static hierarchical relations
A linear client-server relation is formed when a component provides primitive abstractions to another component
A tree-like hierarchy of refinement relations is formed when an abstraction is implemented, and recursively divides into subcomponents. A refinement relation specifies how a module (parent) is decomposed into a refinement module (child).
Different Structure use different element and connectors, and have different performance attributes
What is Software Element ?
At runtime, element is a self-contained component of a system
Software architecture job is map functional requirement to software elements
Rule 1: Reetrant
Reentrant describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users.
A computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing.
A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program.
Handle Bottle-neck first
(1) Wrap it as a separate and highly independent module
(2) Improving its efficiency by replication
(3) Depending on computing needs, allocate cluster or multi-CPU computers for bottle-neck modules in deployment
Make thing simple
Vertical Layer : Each upper layer calls the functionality of lower layers
Horizon Layer: Business logic divided into a sequence of stages
Software Connector
Software Connector
Should be refine within design process
Connector refinement is heavily influenced by project's deployment environment
Usually determines the quality attribute of a system
Availability
Security
Reliability
Efficiency
Can be classify into many categories
Connect the modules of system
Connector Type - Base on Synchronization
Blocking
A blocking connector 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
Non-Blocking
A non-blocking connector allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
Connector Type - Initiator
Two Initiator
either of the two elements can make the request
One-Initiator
It only allows one of the two connected elements initiates the request, but not another way around
Information Carrier
Environment Resource
Message
Method
Variable
Connector Implementation Type
Signature-based
Usually method invocation
Signature: the method name plus the list of parameter types
Method parameter indicates operation type
Protocal-based
A protocol-based connector can implement multiple operation types with a single binding signature
Programmed vs Event Driven
Programmed
A method call will be made at a time specified at programming time
Event-driven
One element will function as an event source
All elements that need be notified of the event will register as listeners of the event source
When the event happens, all the registered listener elements will be notified for potential reaction
Local vs Network
Depend on connector span
Local
Network
Typical Examples
Local method invocation, function call (local)
Distributed Remote Method Invocation (RMI)
Remote Procedure Call (RPC)
Network Connectors need more efforts
Invocation semantics (tricky)
Reliability (hard)
Security (problematic, e.g. RPC)
However, desperately needed by distributed computing environments.
Homogeneous vs. Heterogeneous
Homogeneous
Both Element must be on the same platform
Heterogeneous
Both Element can be on different platform
Agile Design
Traditional Waterfall Approach
Big gap between Requirement specification & Software Architecture
Iterative Refinement
Refine design base on changing requirement
Chapter 3
UML Diagram
Structure Diagram
Package Diagram
Element
package
packageable element
dependency
element import
package import
package merge
Purpose
Shows packages and relationships between the packages
Object Diagram
Notes
(
UML 2.5
) no definition of object diagram.
(
UML 1.4.2
) a class diagram with objects and no classes
Element
instance specification
object
link
slot
Purpose
slots with value specifications
instance specifications of classes and interfaces (objects)
links (instances of association)
Component Diagram
Element
component
provided interface
interface
usage
component realization
port
artiface
required interface
connector
class
Purpose
relationships between above
shows components, provided and required interfaces, ports
Used in
Component-Based Development (CBD) to describe systems with Service-Oriented Architecture (SOA)
Class Diagram
Purpose
Show features,constraints and relationships - associations, generalizations, dependencies, etc.
Shows structure of the designed system, subsystem
Element
feature
association
dependency
constraint
class
inteface
generalization
Common types
diagram of implementation classes
domain model diagram
level of classes and interfaces
Composite Structure Diagram
Show
Internal Structure Diagrams
Element
class
connector
port
part
usage
Purpose
shows internal structure of a classifier
Collaboration Use Diagrams
Behavior
dependency
connector
collaboration specialization
collaboration
part
Purpose
internal structure of a classifier - internal structure diagram,
classifier interactions with environment through ports
a behavior of a collaboration - collaboration use diagram
Deployment Diagram
Element
device
execution
deployment
deployment target
artifact
environment
communication path
node
deployment specification
Note
UML 2.x
artifacts are deployed to nodes, and artifacts could manifest (implement) components
could describe architecture
specification level (also called type level)
instance level (similar to class diagrams and object diagrams)
UML 1.x
components were directly deployed to nodes
Common Type
Instance level deployment diagram
Network architecture of the system
Specification level deployment diagram
Implementation (manifestation) of components by artifacts
Purpose
shows architecture of the system as deployment (distribution) of software artifacts to deployment targets
Represent
The elements the meaningful
concepts
of a system
Profile Diagram
Purpose
describes lightweight extension mechanism to the UML by defining custom stereotypes
tagged values\
constraints
Note
can be dynamically applied to or retracted from a model
Metamodel for different
domains
business process modeling, service-oriented architecture, medical applications, etc.
platforms
Java Platform, Enterprise Edition (Java EE) or Microsoft .NET Framework
can also be dynamically combined so that several profiles will be applied at the same time on the same model
Graphical nodes and edges
profile
stereotype
metaclass
reference
profile application
extension
Show
Static structure
Behavior Diagram
UseCase Diagram
System Use Case Diagrams
Elements
use case
actor
include
extend relationships
subject
Purpose
(external) requirements, required usages of a system under design or analysis (subject) - to capture what the system is supposed to do
the functionality offered by a subject – what the system can do
requirements the specified subject poses on its environment
Business Use Case Diagrams
Elements
business boundary
business use case
extend relationships
include
business actor
represent business function, process, or activity performed in the modeled business
Purpose
describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors)
Notes
UML 2.5 FTF - Beta 1
[UML 2.5 FTF - Beta 1]
UML 2.0 to 2.4
specialization of a class diagram
Activity Diagram
Nodes and edges
activity edge
Include
Interrupting Edge
expressing interruption for regions having interruptions. It is rendered as a lightning-bolt.
object flow edges
The weight
1 more item...
used to show data flow of object and data tokens between action nodes
control edges
is an abstract class for the directed connections along which tokens or data objects flow between activity nodes
activity
actions
Invocations of behavior, such as activities.
Communication actions, such as sending of signals.
Manipulations of objects, such as reading or writing attributes or associations.
Occurrences of primitive functions, such as arithmetic functions.
UML allows behaviors to produce tokens that are activities and which can in turn be executed at the runtime
is a parameterized behavior represented as coordinated flow of actions
Nodes
action
control
object
partition
Constraints
instance
attribute and value
part
classifier
is activity group for actions that have some common characteristic
action
control
object
Purpose
object flow with emphasis on the sequence and conditions of the flow
shows flow of control
Interaction Diagram
Types
sequence diagrams
Nodes and adges
continuation
lifeline
represents an individual participant in the interaction
interaction use
allows to use (or call) another interaction
state invariant
represents a runtime constraint on the participants of the interaction
execution specification
represents a period in the participant's lifetime
message
combined fragment
destruction occurrence
focuses on the message interchange between a number of lifelines
timing diagrams
Notes
Duration Constraint
is an interval constraint that refers to a duration interval
Lifeline
represents an individual participant in the interaction
Time Constraint
is an interval constraint that refers to a time interval
Destruction Occurrence
is a message occurrence which represents the destruction of the instance described by the lifeline
State or Condition Timeline
could show states of the participating classifier or attribute, or some testable conditions
Purpose
show interactions when a primary purpose of the diagram is to reason about time
communication diagrams
Nodes and Edges
lifeline
represents an individual participant in the interaction
frame
Communication diagrams could be shown within a rectangular frame with the name in a compartment in the upper left corner
message
shown as a line with sequence expression and arrow above the line
Purpose
shows interactions between objects and/or parts (represented as lifelines) using sequenced messages in a free-form arrangement
interaction overview diagrams
Purpose
provide overview of the flow of control where nodes of the flow are interactions or interaction uses
Elements
merge node
flow final node
activity final node
join node
fork node
decision node
initial node
could be used on the interaction overview diagrams
duration constraint
time constraint
interaction
interaction use
State Machine Diagram
Types
behavioral state machine
Behavioral Transition
Behavioral State
Kinds
3 more items...
State in behavioral state machines models a situation during which some (usually implicit) invariant condition holds
Vertex
state
pseudostate
State is a vertex which models a situation during which some (usually implicit) invariant condition holds
Final State
Region
Pseudostate
specify discrete behavior of a part of designed system through finite state transitions
protocol state machine
Elements
protocol transition
is specialization of (behavioral) transition used for the protocol state machines which specifies a legal transition for an operation
protocol state
present an external view of the class that is exposed to its clients
pseudostates
is a specialization of behavioral state machine and is used to express usage protocol or lifecycle of a classifier
shows which operations of the classifier may be called in each state of the classifier, under which specific conditions, and satisfying some optional postconditions after the classifier transitions to a target state
Purpose
shows discrete behavior of a part of designed system through finite state transitions
Archirecture View Model
4 + 1 View Model
Process View
Communication Diagrams
Purpose
Capture interactions that show the passed messages between objects and roles within the collaboration scenario
Model message passing between objects or roles that deliver the functionalities of use cases and operations
Support the identification of objects (hence classes), and their attributes (parameters of message) and operations (messages) that participate in use cases
Model alternative scenarios within use cases or operations that involve the collaboration of different objects and interactions
Model mechanisms within the architectural design of the system
Note
The top and the bottom of the rectangle are aligned with the initiation and the completion time respectively.
In communication diagram focus of control is explicit and thus, can be represented by the message nest numbering.
It is an extension of object diagram that shows the objects along with the messages that travel from one to another.
Sequence Diagrams
Note
A person may play the role of several different actors and, conversely, a given actor may be played by multiple different person.
An actor does not necessarily represent a specific physical entity but merely a particular role of some entity
Purpose
Model the interaction between object instances within a collaboration that realizes a use case
Model high-level interaction between active objects in a system
Either model generic interactions (showing all possible paths through the interaction) or specific instances of a interaction (showing just one path through the interaction)
Model the interaction between objects within a collaboration that realizes an operation
Logical View
Object Diagrams
Purpose
During the analysis phase of a project, You might create a class diagram to describe the structure of a system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram.
Before you create a class diagram, You might create an object diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.
Attention: In UML, object diagrams provide a snapshot of the instances in a system and the relationships between the instances. By instantiating the model elements in a class diagram, you can explore the behavior of a system at a point in time.
Class Diagrams
Note
Class Operations
(~) Package
(-) Private
(+) Public
(#) Protected
Class Relationships Type
Simple Association: A structural link between two peer classes.
Dependency: Exists between two classes if changes to the definition of one may cause changes to the other.
Composition: A special type of aggregation where parts are destroyed when the whole is destroyed.
Aggregation: A special type of association. It represents a "part of" relationship.
Inheritance (or Generalization): Represents an "is-a" relationship.
Relationship - Roles
A role is a directional purpose of an association.
Roles are written at the ends of an association line and describe the purpose played by that class in the relationship.
Purpose
Shows static structure of classifiers in a system
Business Analysts can use class diagrams to model systems from business perspective.
Helpful for developers and other team members too
It is used in the design of a system
Composite Structure Diagrams
Purpose
Show internal structure of a classifier - internal structure diagram,
Show a behavior of a collaboration - collaboration use diagram.
Show classifier interactions with environment through ports,
Implementation View
Component Diagrams
Note
it is used for component based system...which include constructed component that can be reused or replaced.
help to understand the structure of existing systems and then build new ones.
Shows components, provided and required interfaces, ports, and relationships between them.
Package Diagrams
Used at level of package
Shows packages and relationships between the packages.
Scenario View
User Stories
Note
Who it is for?
What it expects from the system?
Why it is important (optional?)?
Purpose
Get to small enough chunks that invite negotiation and movement in the backlog
Avoid the appearance of false completeness and clarity
The simple and consistent format saves time when capturing and prioritizing requirements while remaining versatile enough to be used on large and small features alike.
Leave the technical functions to the architect, developers, testers, and so on
Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution.
Keep yourself expressing business value by delivering a product that the client really needs
Use Case
Purpose
Specify the context of a system
Capture the requirements of a system
Developed by analysts together with domain experts
Validate a systems architecture
Drive implementation and generate test cases
Note
Use cases represent only functional requirements of a system.
You can describe those details in other UML diagram types and documents, and have them be linked from use cases.
Physical View
Deployment Diagrams
Used at specification level and instance level.
Purpose: In communication diagram focus of control is explicit and thus, can be represented by the message nest numbering.
Network Topology
