Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chap 1 - 4 - Coggle Diagram
Chap 1 - 4
C1. Introduction to
Software Architecture
OverView
Software Development Life Cycle (SDLC)
Analysis ==>SRS
Software Requirements Specification
Provide input necessary for design
Result of requirement analysis
Record FUNCTIONAL and NON FUNCTIONAL
Design (Architecture & Detail)
===> SDD
Outcome of software
architecture design
is SDD. SDD?
Overall representation of the software to be build
Describes the elements of a system
The modules that compose each element
The detail information of each module
Sample base on IEEE 1016
Design overview, purpose, scope
Decomposition description
Dependency and connection description
Attributes
User interface description
Detailed design
The goal of software design is to build a model that meets all customer requirements and leads to successful implementation
What is the architecture design?
It design defines the relationship between major structural elements
The Styles and design patterns to achieve the requirements
Constraints that effect the way in which architecture can be implemented
Who is responsible for
developing the architecture design?
Software architects and designers
They translate the software system requirements into architecture design
They apply various design strategies to divide and conquer the complexities
Why is software architecture
design so important?
Good Design
Reduce the risks associated with software production
Help development team works together in an orderly fashtion
Make the system traceable for implementation and testing
Lead to software product that have higher quality attributes
Poor Design
Exhibits unpredictable behavior or perform badly
May result in deficient product
Is not adptive to future requirement change
Not reusable
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
Establish dynamic control relationships among different subsystems
Tradeoff analysis on quality attributes
Consider and evaluate alternative architecture styles
Perform static partition and decomposition
Introduce to Software Architecture
Blueprint guideline for development
It is very important in software development
Show how system is sturctured
Hightlights early design decisions
Convers functional and non-functional requirement
Who does the architectural design
System analyst
Software architect
1.3 Architectural Styles
Key components are:
Elements
that perform functions required by a system
Attributes
that describe the advantages and disadvantages of the chosen structure
Connectors
that enable communication, coordination, and cooperation among element
Constraints
that define how elements are integrated to form the system
Why are architecture styles so important?
By indentify the right style to supports software architecture design we can choose which tectics we can use to better implement the architecture
Each style has a set of quality attributes that it promotes
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
Why architectural styles
Architecture style represents
Save cost and time on design
Once overall structure determined, rest are easy
1.4 Quality Attributes
Three catagories
Runtime attributes
Usability
Completeness, correctness, compatibility and user friendliness
Performance
Time efficiency and resource efficiency
Security
The ability to defend against attacks
Availability
If system is available 24/7
Can be enchanced by replication
Business attributes
Time to market
The time it takes from requirement analysis to the product is released
Cost
Expense of the building, maintaining, and operating the system
Lifetime
The period of time that the product is alive before retirement
Implementation attributes
Scalability
Can system adapt to increase of requests
Portability
Can be system be deployed on different platforms
Flexibility
Ease of modification of system to cater to a different environment
Maintainability & Extensibility
The ability to modify the system and conveniently extend it
Testability
Whether the system allows easy debugging
Each architeture style has its advantages, disadvantages, and potential risks. So choosing the right style to satisfy required function and quality is very important
Quality Attribute Trade-off
Scalability vs Performance
Reliability vs Performance
Space vs Time
Qualily attributes are identified in requirement analysis process
1.5 Software architecture design guidelines
Guideline 2: Think about abstract design before thinking about concrete design.
Use multiple level of abstraction if necessary
Nail down the interface but leave room of change for implementation
Always starts with abstraction
Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
Use abstract architectural design to communicate with stakeholders helps avoid overhauling the system design in later stage
Guideline 7: Avoid ambiguous design and over-detailed design.
Over-detailed design restricts implementation.
Ambiguous design lacks constraints
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 5: High Cohesion and Loose Coupling
One component (module) should be assigned ONE functionality only
Easy debugging and maintenance
The less correlation between modules, the better!
Design should be logically clear!
Try to promote high cohesion within each element and loose-coupling between elements.
Also allows great extensibility
Guideline 1: Think of What to Do before How to Do It.
System requirements must be nailed down before design starts
Notice, different stakeholder have different opinions
Clarify priority of all requirements before design
Guideline 4: Think of reusability and extensibility!
User requirements can change frequently
Extensibility is very important
Leave the room for expansion
Consider how resuse existing software components to increase the reliability and cost-effectiveness of new systems.
Always try hard to make software extensible in the future.
Guideline 3: Think of non-functional requirements early in design process
Balance the quality attributes, and consider heterogeneous architecture styles when necessary
The earlier, the better
Otherwise, very hard to change your design to reflect these requirement
Speed, Reliability, Security have to be considered first
It is not possible to find a design that meets all quality attribute
C2. Software Architecture Design Space
Software Architects Job
Map functional requirements to software elements
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
it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing
making sure that no instruction modify the contents of variable values in other instructions within the program
Rule 2: Handle Bottle-Neck First
Treat bottle-neck functionality using approaches
allocate cluster or multi-CPU computers for bottle-neck modules in deployment
Wrap it as a separate and highly independent module
Improving its efficiency by replication
Rule 3: Make Things Simple
Split it into smaller ones
Vertical Layers
Horizontal Layers
Types of Software Structures
Static Structure
A software project is typically implemented in multiple files
The connectors at this level are in the form of module dependency
Static connectors may exhibit some attributes
Direction
Synchronization
Sequence
Runtime Structure
Run-time Connector Properties
inherit attributes from their source-code structure counterparts, with a few extra attributes
Multiplicity
One element can be connected to multiple elements
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 invocable
irrespective of hardware/software platform, and programming languages
Self-descriptive
allows clients to choose service providers dynamically
A runtime project consists of elements
Threads
Distributed objects
Web services
Processes
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
Management Structure
Can be used for resource allocation
Software Connector
Connector type
Non-blocking
allows one of its incident elements to send a request to another and continues its execution without waiting for a response
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
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
determines the quality attributes of a system
Reliability
Security
Availability
Efficiency
Implementation type
Signature based
Method parameter indicates operation type
Usually method invocation
Protocol based
A protocol-based connector can implement multiple operation types with a single binding signature
Connects the modules of a system
refined within the design process
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
Design space
design alternatives that can support functional and
non-functional requirement specifications
C.3 Models for Software Architecture
3.1: Overview
There are five views in the model
The logical view
Is used to identify software modules and their boundaries, interfaces, external environment, usage scenarios, etc.
The process view
Addresses non-functional requirements such as module communication styles and performance issues at runtime.
The physical view
Specifies the deployment infrastructure in terms of software, hardware, and networking configurations, installation, and deployment for delivery purposes.
The development view
Organizes the software units in well-defined ways according to the actual file or directory structure.
The user interface view
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
The “4+1” view model is another way to show different views of the functional and non-functional requirements of the software project
Software architecture specifies a high-level of abstraction of a software system by employing decomposition, composition, architectural styles, and quality attributes.
Box-and-line diagrams will be used throughout this book for specification purposes
It must also specify the deployment configuration of all components and connections.
3.3: Structural (Stattic) Diagrams
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.
Component
Is neither a class nor an object.
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.
Is a deployable reusable building block for software design and development.
The interface is the contract between reusable component and its clients.
Each component has an interface to expose its services and hides its implementations.
Class
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.
Is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle.
Popular accessibility modifiers include private, public, protected, and default
One important part of a class diagram is the interface of each 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.
Provides a static view of the system. It captures the vocabulary of the designed system.
Describe each individual class with its type, interface, properties, and methods.
Deployment
Depict the physical configuration of the software system deployed on hardware server nodes and the network between the nodes (defined as protocols).
UML uses a cube symbol to represent a computing resource node; such a resource can be a hardware device or a deployed software subsystem.
All components in the system need to be deployed on servers to provide services via network protocols.
Is generated in the later phase of software development life cycle.
Component diagrams are the basis for the deployment diagram.
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.
Package
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.”
Is represented by a tabbed folder that indicates where all included classes and sub packages reside.
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.
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.
The use of package diagrams to represent system structure can help reduce the dependency complexity and simplify relationships between groups of classes.
3.4: Behavioral (Dynamic) Diagrams
Interaction Overview Diagram
Is a variant of the Activity 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.
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
Describes the control flow of the interactions rather than message.
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 activities
State name
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.
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).
Timing Diagram
Is often used in time-critical systems such as real time operating system, embedded system design, etc.
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.
Communication or Collaboration Diagram
Is an extension of the static object diagram where the links between objects represent the association relationships.
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.
Summarizes how objects in the system receive and send messages from/to other objects.
These two type of diagrams provide a message-oriented and time-oriented view, respectively.
Above the links in a communication diagram are the numbered messages, indicating the order in which they are sent or received.
Sequence Diagram
An object can send a synchronous message to another object by a synchronous message line with a full arrowhead.
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.
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.
Usually, one sequence diagram corresponds to one use case.
is one of the most important and most widely used UML diagrams for software system analysis and design.
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.
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.
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.
Describe user requirements in terms of system functionality (use cases) as a contract between the user (actors) and the software system.
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.
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.
The (simple) connection link from actor to use case shows the direction of actors using the 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.
It consists of actors, use cases and links between them.
Each use case is a meaningful operational work scenario.
Activity Diagram
A small diamond represents a decision point in the diagram.
Is a workflow-oriented diagram describing steps on a single process.
Also support parallel processing using a pair of black horizontal bars to indicate the corresponding fork/join actions in such pathways.
One activity diagram corresponds to one business process. There are many activities in a business process.
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).
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.
Is used to describe complex business processes
3.2: UML for Software Architecture
The related UML diagrams are sequence diagram, collaboration diagram, activity diagram, etc.
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.
Provides several modeling diagrams that can be grouped into two major categories: Structural (static) and Behavioral (dynamic).
Object Oriented Paradigm (OOP)
7 Basic Design Patterns OOP
State
Nó cho phép một đối tượng thay đổi hành vi của nó khi trạng thái nội bộ của nó thay đổi. Đối tượng sẽ xuất hiện để thay đổi lớp của nó.
Factory Method
Factory Pattern là một trong những Pattern thuộc nhóm Creational Design Pattern. Nhiệm vụ của Factory Pattern là quản lý và trả về các đối tượng theo yêu cầu, giúp cho việc khởi tạo đổi tượng một cách linh hoạt hơn.
Strategy
Nó cho phép định nghĩa tập hợp các thuật toán, đóng gói từng thuật toán lại, và dễ dàng thay đổi linh hoạt các thuật toán bên trong object. Strategy cho phép thuật toán biến đổi độc lập khi người dùng sử dụng chúng.
Adapter
Adapter Pattern cho phép các inteface (giao diện) không liên quan tới nhau có thể làm việc cùng nhau. Đối tượng giúp kết nối các interface gọi là Adapter.
Builder
Builder pattern là mẫu thiết kế đối tượng được tạo ra để xây dựng một đôi tượng phức tạp bằng cách sử dụng các đối tượng đơn giản và sử dụng tiếp cận từng bước, việc xây dựng các đối tượng đôc lập với các đối tượng khác.
Observer
Nó định nghĩa mối phụ thuộc một – nhiều giữa các đối tượng để khi mà một đối tượng có sự thay đổi trạng thái, tất các thành phần phụ thuộc của nó sẽ được thông báo và cập nhật một cách tự động.
Singleton
Singleton đảm bảo chỉ duy nhất một thể hiện (instance) được tạo ra và nó sẽ cung cấp cho bạn một method để có thể truy xuất được thể hiện duy nhất đó mọi lúc mọi nơi trong chương trình.
OPP Characteristics
Classes
For example planets, sun and moon are the members of the solar system class.
A class is a collection of objects that have identical properties, common behaviour and shared relationship.
The objects can be made user-defined data types with the help of a class.
Once the class is defined any number of objects of that class is created.
Classes are user-defined data types A class can hold both data and functions.
Encapsulation
:
Tính năng đóng gói là thu thập dữ liệu và lưu giữ dữ liệu đó một cách an toàn và bảo mật khỏi các giao diện bên ngoài =>
Dễ sử dụng đơn giản hóa
.
The wrapping of data and function into a single unit is called data encapsulation.
Data encapsulation enables data hiding and information hiding.
Abstraction
:
Khả năng biểu diễn dữ liệu ở mức rất khái niệm mà không cần bất kỳ chi tiết nào.
Abstract class:
Interface:
Khá giống với abstract class nhưng interface không phải là class, trong interface chỉ có khai báo những method/properties trống không có thực thi, thực thi sẽ được thể hiện trong các lớp kế thừa, interface giống như một cái khung mẫu để các lớp implement và follow.
Data abstraction refers to the process of representing essential features without including background details or explanations.
Polymorphism
:
Đây là khả năng tồn tại dưới nhiều hình thức khác nhau. Ví dụ, một toán tử có thể được nạp chồng để thêm hai số nguyên và hai số thực
The different types of polymorphism are operator
Multiple forms are known as polymorphism.
The ability of an operator and function to take.
Function overloading, function overriding.
Objects
An object may represent a person, place or a table of data.
Objects are basic building blocks for designing programs.
An object is a collection of data members and associated member functions.
Example: chair, table, whiteboard are the objects of the class (class).
Each object is identified by a unique name. Each object must be a member of a particular class.
Inheritance
:
Đây là quá trình mà một lớp có thể được dẫn xuất từ một lớp cơ sở với tất cả các tính năng của lớp cơ sở và một số tính năng của riêng nó. Điều này làm tăng khả năng tái sử dụng mã.
The existing class is known as a base class or superclass.
Inheritance is the process by which one object can acquire and the use of properties of another object.
The derived class shares some of the properties of the base class. Therefore a code from a base class can be reused by a derived class.
The new class is known as a derived class or subclass.
SOLID Principles
:SOLID is a mnemonic invented by
Michael Feathers
S
: Single responsibility principle
Một class chỉ nên giữ 1 trách nhiệm duy nhất
(Chỉ có thể sửa đổi class với 1 lý do duy nhất)
Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) không nên sửa đổi class cũ.
D
: Dependency inversion principle
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.
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.)
L
: Liskov substitution principle
Trong một 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
I
: 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ể
O
: Open/closed principle
Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó => Kế thừa
(open for extension but closed for modification).
Define
: OOP là một mô hình lập trình dựa trên khái niệm sử dụng các lớp và đối tượng trong mã lập trình của bạn. Lập trình hướng đối tượng (OOP) được sử dụng để cấu trúc ngôn ngữ lập trình thành các đoạn mã đơn giản, có thể tái sử dụng thường được gọi là các lớp, chúng ta có thể sử dụng như một người dùng định nghĩa Kiểu dữ liệu để tạo các thể hiện của đối tượng.