Please enable JavaScript.
Coggle requires JavaScript to display documents.
SWD chap 1 - 4 - Coggle Diagram
SWD chap 1 - 4
Introduction to Software Architecture
Overview
The goal of software design
build a model that meets all customer requirements
The software architecture design
WHAT
The relationship between major structural elements of the software, the styles and design patterns
WHO
(responsibility)
Software architects and designers (map from the software system requirements)
WHY
The poor design
Software production is inefficient in terms of time and cost
Do not meet system requirements
Performs bad
...
The good design
Reduces the risks associated with software production
Helps development teams work together in an orderly fashion
Makes the system traceable for implementation and testing
Leads to software products that have higher quality attributes
WHEN
A phase of the Software Development Life Cycle
(SDLC)
Software requirements analysis
Software design (architecture and detailed)
Software development and implementation
Testing and quality assurance, maintenance, and evolution
Input
Software Requirements Specification
(SRS)
The result of requirements analysis
Records the functional and nonfunctional requirements
Output
Software Design Description
(SDD)
The blueprint for the implementation phase
The software architecture or high-level design
The detailed design of the system.
Describes
The components of a system
The modules that comprise each component
The detailed information of each module
(data attributes, operations, and algorithms)
Sample outline of SDD
based on IEEE Std 1016
Design overview, purpose, scope
Dependency and connection description
(between modules, data, and processes)
Attributes
User interface description
Detailed design (module and data)
Steps
The architecture design
User-accessible elements
Interconnections that are visible to stakeholders
The detailed design
(Tactical design)
The internal details of each element
Might introduce new invisible components
Software Architecture: Bridging Requirements and Implementation
Plays a very important role in
the Software Development Life Cycle
The architecture design
Provides a blueprint and guideline for developing a software system based on its requirement analysis specification
Embodies the earliest decisions that have a decisive impact on the ultimate success of the software product
Cover the software's functional and nonfunctional requirements
sub-system
A sole responsibility
(business logic processing, logic control, interface presentation, data gathering, and service brokering and mediating)
Division based on function image, location and runtime
Dynamic runtime connector
Be batch-sequential, multithreaded, implicit indirect invocation, synchronous or asynchronous communication, etc
Define
IEEE Std 1471
The fundamental organization of a system embodied in its elements, their relationships to each other, and to the environment, and the principles guiding its design and evolution
Garlan and Shaw
The description of elements that comprise a system, the interactions and patterns of these elements, the principles that guide their composition, and the constraints on these elements
The requirements process
Information domain modeling
Data modeling
Function modeling
Behavioral modeling
User interface modeling
Aspects of software requirements
Functional requirement
Specifies the functionality of the software system
Non-functional requirement
Specifies system qualities, constraints, and behaviors
Software architect's tasks
Perform
System static partitioning
System decomposition
A software element can be configured, delivered, developed,
and deployed, and is replaceable in the future
Each element's interface encapsulates details and
provides loose coupling with other elements or subsystems.
Establish dynamic control relationships among different subsystems in terms of data flow,
control flow orchestration, or message dispatching
Consider and evaluate alternative architecture styles
that suit the problem domain at hand
Perform tradeoff analysis on quality attributes and other non-functional requirements during the selection of architecture styles
The most important jobs
Map the software requirements specification to the software architecture
Guarantee that functional and nonfunctional requirements are met
Architecture Styles
(architecture pattern)
Abstracts the common properties of a family of similar designs
Contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
Governs the overall structure design pattern of constituent element types and their runtime interaction of flow control and data transfer
The key components
Elements
perform functions required by a system
Connectors
enable communication, coordination,
and cooperation among elements
Constraints
define how elements can be integrated to form the system
Attributes
describe the advantages and disadvantages of the chosen structure
Quality Attributes
Implementation attributes (not observable at runtime)
Maintainability & Extensibility:
The ability to modify the system and conveniently extend it
Testability:
Whether the system allows easy debugging
Portability
: Can the system be deployed on different platforms
Scalability:
Can system adapt to increase of requests
Flexibility:
Ease of modification of system to cater to a different environment
Interoperability
: universal accessibility and the ability to exchange data among internal components and with the outside world.
Run-Time Attributes
Availability
be available 24/7
can be achieved via replication and careful design to cope with failures of hardware, software, or the network.
Security
The ability to defend against attacks
Improve by installing firewalls, establishing authentication and authorization processes, and using encryption.
Performance:
Time efficiency and resource efficiency
Reliability
: the failure frequency, the accuracy of output results, the Mean-Time-to-Failure (MTTF), the ability to recover from
failure, and the failure predictability.
Maintainability
: extensibility, adaptability, serviceability, testability, compatibility, and configurability
Usability
: Completeness, correctness, compatibility and user friendliness
Business attributes
Time to market
: The time it takes from requirement analysis to the product is released
Cost
: the expense of building, maintaining, and operating the system.
Lifetime
: the period of time that the product is “alive” before retirement.
Summary
A software architecture specification
consists of software elements, connectors and collaborations among the elements, and desired quality attributes
An architecture style
is a set of rules, constraints, or patterns that guide how to structure a system into a set of elements and connectors, and how to govern overall structure design patterns of constituent element types and their runtime interaction
Note
: One specific architecture style may not
satisfy all of the system's desired quality attributes, in which case tradeoffs must be made
Software architecture design guidelines
Think of What to Do before How to Do It
Think about abstract design before thinking about concrete design
Think of non-functional requirements early in design process
Think of reusability and extensibility!
High Cohesion and Loose Coupling
Tolerate refinement of design
Avoid ambiguous design and over-detailed design
Chap 2: Software Architecture Design Space
Software elements
At runtime, element is a self-contained component of a system
Has well-defined functions
Usually interface is public and fixed
Implementation can change with the time
Connected with each other via connector
Software Connector
Connect the modules of a system
Should be refined within the design process.
Connector refinement is heavily influenced by a project’s deployment environment
Usually determines the quality attributes of a system
Efficiency
Reliability
Availability
Security
Can be classified into many categories
Connector type – Based on Synchronization
Blocking
A blocking connector allows one of its incident elements to send a request to another and be blocked 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
One Initiator
It only allows one of the two connected elements initiates the request, but not another way around
Two Initiator
either of the two elements can make the request
Connector information Carrier
Variable
for elements in the same process
Environment resource
for elements in different processes of the same system
Method
Local invocation
Remote invocation
Message
A message format must be defined so both the message sender and the message receiver can understand the messages
A protocol must be adopted to decide the proper handshaking and synchronization between the two parties
Connector Implementation type
Signature based
Usually method invocation
Signature: the method name plus the list of parameter types
Method parameter indicates operation type
Protocol based
A protocol-based connector can implement multiple operation types with a single binding signature
Based on connector’s active time
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
Depending on connector span
Network Connectors need more efforts
Invocation semantics (tricky)
Reliability (hard)
Security (problematic, e.g. RPC)
However, desperately needed by distributed computing environments
Local
Homogeneous vs. Heterogeneous
Homogeneous:
both elements must be on the same platform
Heterogeneous:
both elements can be on different platforms
Perspectives
Software Static Structure
Files
Binary software component modules
JavaBeans
DLL
Deployment descriptors
Library files
Others resources files
Executable files
Software development
source code modules or files
functional and nonfunctional attributes
API defined
Implementation
Interface
module dependency
Static connectors
Direction
Synchronization
Sequence
Managing static structures
Refinement showing visibility
Abstraction for encapsulation
Two kinds of static hierarchical relations
Tree-like hierarchy of refinement relations
Linear client-server relation
Run-time Structure
Elements
Threads
Web services
Processes
Distributed objects
Attributes
Inherit
Extra
Universal invocable
Invoke its methods irrespective of hardware/software platform, programming languages.
Important for heterogeneous system.
Self-descriptive
Clients choose service providers dynamically.
Invoke its method without pre-installation of any software specific to the method.
Distance and connection media
Two connected element may communicate in the same thread, process , same, different computers across a network.
Media: Copper/optical, Wired/wireless LAN
Decides performance and reliability
Multiplicity
One element can be connected to multiple elements.
Management/deployment structure
Designed and implemented by several project teams with its well-defined responsibilities.
Can be used for resource allocation.
Overview
Software architecture design is a set of software elements connected by a set of connectors.
Software architect must understand the software architecture's design space.
Agile Design
Interative Refinement
Traditional Water-Fall Approach
Software Architecture
Requirement Specification
Refine designs based on changing requirement
Chap 3: Models for Software Architecture
3.2.1.Structural (Static) Diagrams
Class Diagram
It is the foundation diagram of the system design and it is the most frequently used UML diagram as well.
Class diagrams can be derived from use case diagrams or derived from text analysis on the given problem domain.
A class diagram is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle.
Class diagrams describe each individual class with its type, interface, properties, and methods.
The accessibility (visibility) of each attribute and operation can also be specified.
This diagram provides a static view of the system. It captures the vocabulary of the designed system.
Popular accessibility modifiers include private, public, protected, and default.
Component Diagram
A component is neither a class nor an object.
A component is a deployable reusable building block for software design and development.
Each component has an interface to expose its services and hides its implementations.
Package Diagram
A package is represented by a tabbed folder that indicates where all included classes and sub packages reside.
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.”
Deployment Diagram
Deployment diagrams depict the physical configuration of the software system deployed on hardware server nodes and the network between the nodes (defined as protocols).
This diagram is generated in the later phase of software development life cycle.
Component diagrams are the basis for the deployment diagram.
3.3 Architecture View Models
'
'
'
'
'
'
A model is a complete, simplified description of a system from a particular perspective or viewpoint.
There is no single view that can present all aspects of complex software to stakeholders.
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.
The 4+1 view model is a multiple-view model that addresses different aspects and concerns of the system.
The 4+1 view model standardizes the software design documents and makes it easy to understand by all stakeholders.
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.
'
1 more item...
3.2.2.Behavioral (Dynamic) Diagrams
Use Case Diagram
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.
Each use case 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.
The (simple) connection link from actor to use case shows the direction of actors using the use case.
Type of link
<<include>> link
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.
Is a dashed line with an arrow pointing to the reused use case
An <<extend>> link
Shows a newly created optional use case from an existing use case.
It covers alternative cases that may or may not necessarily take place.
Is also a dashed directed line with an arrow towards the extended use case; these special links are labeled accordingly.
It consists of actors, use cases and links between them.
The detailed steps are specified in a separate note including the pre and post conditions of the action in the sequence.
Sequence Diagram
Is a time-oriented interaction diagram showing the chronological sequence of messages between objects.
One of the most important and most widely used UML diagrams for software system analysis and design.
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.
Usually, one sequence diagram corresponds to one use case.
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.
Each participant object in this diagram has a vertical timeline for its life cycle
An activation may also branch or fork many separate lifelines for the if-selection scenario conditions; eventually all forked lines will join together.
Each activation box may also have a self-recursive directed link pointed back to itself, indicating the object passes messages to itself.
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.
State Machine Diagram
In a state machine diagram, a state is a rounded rectangle with three subdivisions
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.
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).
Called state charts in UML 1.x, are widely used for embedded systems and device software analysis and design.
Are ideal for specifying the internal behavior of objects.
Element of State Diagram:
State name
State activities
State variables
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).
Activity Diagram
Also support parallel processing using a pair of black horizontal bars to indicate the corresponding fork/join actions in such pathways.
A small diamond represents a decision point in the diagram.
Each activity diagram starts with a starting point and finishes with one or more finishing points.
UML activity diagrams use a rounded rectangle to represent an activity.
One activity diagram corresponds to one business process. There are many activities in a business process.
Is a workflow-oriented diagram describing steps on a single process.
Is used to describe complex business processes
Chap 4: Object Oriented Paradigm
OOP Characteristics
Inheritance
One class inherits the attributes and methods of another class include private, protected, public, default
Can access to public, default, protected
Avantaged
save the number of lines of code
save development time
Cost savings
allows programmers to create a new class that reuses the data members and methods of an existing class.
Polymorphism
Allows an object to behave in multiple forms depending on the context.
Includes
Vertical override operations between parent classes and derived classes.
Horizontal overloading operations within the same class.
Encapsulation
Some reason to use
The functionality is defined in one place and not in multiple places.
When we use a method, we only need to know what result the method will produce – we don’t need to know details about the object’s internals in order to use it
allow for flexibility in design, easy team working
The goal is not security, it's a simplified object that needs to be used because it doesn't appear to have complicated changes from the outside.
methods and fields are private so that external classes and external entities cannot see them
Abstraction
"Shows" only essential attributes and "hides" unnecessary information.
Main purposes
Hiding the unnecessary details from the users.
Reducing programming complexity and efforts.
Abstract class
A base class for all derived classes of the same nature
Abstract medthod
A method without body
Must be declared in an abstract class.
SOLID Principles
Interface Segregation Principle
Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể
Dependency inversion principle
Interface(abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại
(Các class giao tiếp với nhau thông qua interface,
không phải thông qua implementation)
Các module cấp cao không nên phụ thuộc vào các modules cấp thấp
Cả 2 nên phụ thuộc vào abstraction
Single responsibility principle
A class should have one and only one reason to change, meaning that a class should have only one job
Open-Closed Principle
Objects or entities should be open for extension but closed for modification.
Liskov Substitution Principle
Trong 1 chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình
