INTRODUCTION TO SOFTWARE ARCHITECTURE - Coggle Diagram
INTRODUCTION TO SOFTWARE ARCHITECTURE
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 ?
May result deficient product
Is not adaptive to future requirement changes
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
Specification Analysis ==> SRS
Testing and maintenance
Serve as contract between Developer and customer
System constraint and pre-condition
Software Design Description (SDD)
Component of the systemt
Module of each Component
Detail information of each module
Software Design Description (SDD): an overall representation of the software to be build.
2 Step In Software 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
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
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
Time to market
Maintainability & Extensibility
Universal accessibility and ability to exchange data among internal components and the outside world
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
4 Principles of OOP
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.
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.
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.
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
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
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
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
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
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
Others Resource Files
Static Connector may exhibit some attribute
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
Should be refine within design process
Connector refinement is heavily influenced by project's deployment environment
Usually determines the quality attribute of a system
Can be classify into many categories
Connect the modules of system
Connector Type - Base on Synchronization
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
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
either of the two elements can make the request
It only allows one of the two connected elements initiates the request, but not another way around
Connector Implementation Type
Usually method invocation
Signature: the method name plus the list of parameter types
Method parameter indicates operation type
A protocol-based connector can implement multiple operation types with a single binding signature
Programmed vs Event Driven
A method call will be made at a time specified at programming time
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 method invocation, function call (local)
Distributed Remote Method Invocation (RMI)
Remote Procedure Call (RPC)
Network Connectors need more efforts
Invocation semantics (tricky)
Security (problematic, e.g. RPC)
However, desperately needed by distributed computing environments.
Homogeneous vs. Heterogeneous
Both Element must be on the same platform
Both Element can be on different platform
Traditional Waterfall Approach
Big gap between Requirement specification & Software Architecture
Refine design base on changing requirement
Shows packages and relationships between the packages
) no definition of object diagram.
) a class diagram with objects and no classes
slots with value specifications
instance specifications of classes and interfaces (objects)
links (instances of association)
relationships between above
shows components, provided and required interfaces, ports
Component-Based Development (CBD) to describe systems with Service-Oriented Architecture (SOA)
Show features,constraints and relationships - associations, generalizations, dependencies, etc.
Shows structure of the designed system, subsystem
diagram of implementation classes
domain model diagram
level of classes and interfaces
Composite Structure Diagram
Internal Structure Diagrams
shows internal structure of a classifier
Collaboration Use Diagrams
internal structure of a classifier - internal structure diagram,
classifier interactions with environment through ports
a behavior of a collaboration - collaboration use diagram
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)
components were directly deployed to nodes
Instance level deployment diagram
Network architecture of the system
Specification level deployment diagram
Implementation (manifestation) of components by artifacts
shows architecture of the system as deployment (distribution) of software artifacts to deployment targets
The elements the meaningful
of a system
describes lightweight extension mechanism to the UML by defining custom stereotypes
can be dynamically applied to or retracted from a model
Metamodel for different
business process modeling, service-oriented architecture, medical applications, etc.
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
System Use Case Diagrams
(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
business use case
represent business function, process, or activity performed in the modeled business
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)
UML 2.5 FTF - Beta 1
[UML 2.5 FTF - Beta 1]
UML 2.0 to 2.4
specialization of a class diagram
Nodes and edges
expressing interruption for regions having interruptions. It is rendered as a lightning-bolt.
object flow edges
1 more item...
used to show data flow of object and data tokens between action nodes
is an abstract class for the directed connections along which tokens or data objects flow between activity nodes
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
attribute and value
is activity group for actions that have some common characteristic
object flow with emphasis on the sequence and conditions of the flow
shows flow of control
Nodes and adges
represents an individual participant in the interaction
allows to use (or call) another interaction
represents a runtime constraint on the participants of the interaction
represents a period in the participant's lifetime
focuses on the message interchange between a number of lifelines
is an interval constraint that refers to a duration interval
represents an individual participant in the interaction
is an interval constraint that refers to a time interval
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
show interactions when a primary purpose of the diagram is to reason about time
Nodes and Edges
represents an individual participant in the interaction
Communication diagrams could be shown within a rectangular frame with the name in a compartment in the upper left corner
shown as a line with sequence expression and arrow above the line
shows interactions between objects and/or parts (represented as lifelines) using sequenced messages in a free-form arrangement
interaction overview diagrams
provide overview of the flow of control where nodes of the flow are interactions or interaction uses
flow final node
activity final node
could be used on the interaction overview diagrams
State Machine Diagram
behavioral state machine
3 more items...
State in behavioral state machines models a situation during which some (usually implicit) invariant condition holds
State is a vertex which models a situation during which some (usually implicit) invariant condition holds
specify discrete behavior of a part of designed system through finite state transitions
protocol state machine
is specialization of (behavioral) transition used for the protocol state machines which specifies a legal transition for an operation
present an external view of the class that is exposed to its clients
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
shows discrete behavior of a part of designed system through finite state transitions
Archirecture View Model
4 + 1 View Model
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
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.
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
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
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 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.
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
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,
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.
Used at level of package
Shows packages and relationships between the packages.
Who it is for?
What it expects from the system?
Why it is important (optional?)?
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
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
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.
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.