Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chap 1,2,3,4 - Coggle Diagram

- - - - “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” (Maier, Emery, Hilliard).
    - - “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” (1996).
    - - Functional
        
        A functional requirement specifies the functionality of the software system
      - Nonfunctional
        
        Nonfunctional requirement specifies system qualities, constraints, and behaviors.
    - - Perform static partition and decomposition of a system into subsystems and communications among subsystems
      - Establish dynamic control relationships among different subsystems in terms of data flow, control flow orchestration (điều phối luồng điều khiển), or message dispatching
      - Consider and evaluate alternative architecture styles that suit the problem domain at hand.
      - Perform tradeoff analysis on quality attributes and other nonfunctional requirements during the selection of architecture styles.
    - - Map the Software Requirements Specification to the software architecture design
      - Guarantee that functional and nonfunctional requirements are met
  - - - Elements that perform functions required by a system
      - Connectors that enable communication, coordination, and cooperation among elements
      - Constraints that define how elements can be integrated to form the system
      - Attributes that describe the advantages and disadvantages of the chosen structure
    - - Consists of three element types
        
        Client
        
        Responsible for GUI interface presentation, accepting user requests, and rendering results
        
        Middleware server
        
        The middleware element gets the requests from the client element, processes the requests based on the business logic, and sends a data request to the back-end tier
        
        Data server.
        
        The data store server element manages data querying and updating.
      - Multi-tier architecture is commonly used for distributed systems.
      - Many enterprise software architectures are of the multi-tier style because they share the same set of constraints
    - - Because each style has a set of quality attributes that it promotes
      - Identifying the styles => can verify whether the architecture is consistent with the requirement specifications, and identify which tactics we can use to better implement the architecture
  - - - build a model that meets all customer requirements and leads to successful implementation
    - - Poor design
        
        result in a deficient product that does not meet system requirements
        
        not adaptive to future requirement changes,
        
        not reusable
        
        exhibits unpredictable behavior
        
        performs badly.
      - Good software design
        
        helps development teams work together in an orderly fashion
        
        reduces the risks associated with software production
        
        the system traceable (có thể theo dõi ) for implementation and testing
        
        software products that have higher quality attributes
    - - defines the relationship between major structural elements of the software
      - The styles and design patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented
    - - Software architects and designers
    - - Software design is an early phase of the Software Development Life Cycle
      - Software Development Life Cycle (SDLC)
        
        software design (architecture and detailed)
        
        software development and implementation
        
        testing and quality assurance
        
        software requirements analysis
        
        Maintenance and evolution
    - - overall representation of the software to be built
      - Software Design Descriptions (SDD)
        
        the blueprint for the implementation phase. It describes the elements of a system
        
        The modules that compose each element and the detailed information (such as data attributes, operations, and algorithms) of each module
        
        The SDD is used as a template for software design description
    - - provides the input necessary for design
      - SRS is the result of requirements analysis
      - it records the functional and nonfunctional requirements that must be met by the software
    - - Architecture design
        
        designer must specify user-accessible elements
        
        front strategy design for the detailed design
        
        the interconnections that are visible to stakeholders
      - Detailed design (tactical design)
        
        local design constraints and the internal details of each element
  - - - Availability
        
        Increasing a system's efficiency with regard to response time, throughput, and resource utilization, attributes
        which usually conflict with each other.
      - Performance
        
        The level of human satisfaction from using the system
      - Security
        
        A system's ability to cope with malicious attacks from outside or inside the system
      - Usability
        
        The failure frequency, the accuracy of output results, the Mean-Time-to-Failure (MTTF), the ability to recover from failure, and the failure predictability.
      - Reliability
        
        A system's capability to be available 24/7.
      - Maintainability (extensibility, adaptability, serviceability, testability, compatibility, and configurability)
        
        The ease of software system change.
    - - Cost
        
        the expense of building, maintaining, and operating the system.
      - Lifetime
        
        the period of time that the product is “alive” before retirement.
      - Time to market
        
        the time it takes from requirements analysis to the date a product is released
    - - Portability
        
        The system's level of independence on software and hardware platforms.
      - Maintainability and extensibility
        
        The ability to modify the system and conveniently extend it.
      - Scalability
        
        A system's ability to adapt to an increase in user requests
      - Interoperability
        
        Universal accessibility and the ability to exchange data among internal components and with the outside world
      - Flexibility
        
        The ease of system modification to cater to different environments or problems for which the system was not originally designed
      - Testability
        
        The degree to which the system facilitates the establishment of test cases
    - - Tradeoff between space and time
      - Tradeoff between reliability and performance
      - Tradeoff between scalability and performance
  - - - Functional and nonfunctional requirements should be identified, verified, and validated before architecture and detailed design work is done
      - Using an abstract architecture design to communicate with stakeholders helps avoid the need to overhaul the system design in later stages of the software development cycle.
    - - Use multiple levels of abstraction if necessary
      - Make implementation decisions based on the abstract interfaces instead of the concrete ones because those are more stable
      - Always start with an abstract design that specifies interfaces of components and abstract data types
    - - When you map functional requirements to an architecture design, you should consider nonfunctional requirements as wel
    - - Always try hard to make software extensible in the future
    - - A highly coherent subsystem, component, or module performs one sole function
    - - Ambiguous design lacks constraints and over-detailed design restricts implementation.
- - - - Has well-defined functions
        
        Implementation can change with the time
        
        Usually interface is public and fixed, and
    - - If an element has high multiplicity and its performance is important to the global system performance, an application server (a
        software system running business logics) should be used for the element's implementation so that it can take advantage of thread
        and resource pooling, data caching, and dynamic element life cycle management to conserve resources.
      - A complex element can be expanded into a subsystem with its own elements and connectors. A well-defined interface should be
        used to encapsulate the subsystem's design and implementation details from the existing architecture.
      - If an element is not reentrant and multiple threads or processes need to communicate with it, it must be run on separate threads or
        processes in order to be thread-safe (meaning that the system behavior is not affected by the multiplicity of threads executing
        concurrently).
      - If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data
        processing power. The cluster size and the elements' mapping to the cluster computers should be done carefully to balance each
        cluster's computation load and minimize the total communication traffic on the cluster's network
      - Rule 1: Reetrant(Tái xuất)
        
        If an element is reentrant, it can be implemented by a thread or a process. Reentrant elements are usually more efficient because
        they avoid many synchronization issues and support shared thread or process pools. However, business logics may not allow some
        elements to be reentrant.
      - If an element is assigned complex but well-defined functions, similar to those of some commercial off-the-shelf software components,
        and the performance of this element is not critical, then it is more cost-effective to use an existing software component to implement
        the element's functions.
      - A complex element can be transformed into a sequence of horizontally tiered elements if the business logic can be achieved by
        processing data with a sequence of discrete processing stages, and these processing stages can be implemented by tiered
        elements with well-defined interfaces and balanced workloads.
      - A complex element can be transformed into a sequence of vertical layered elements if each layer provides a virtual machine or
        interface to its immediate upper-layer element, and each layered element hides away some low-level system details from the upper
        layers.
  - - - An initiator
        
        an incident element of a connector that can make a request to its partner
      - two-initiator
        
        connector allows either one of its two incident elements to make a request to the other element
    - - Local connectors
      - Networked connectors
      - depends on whether the incident elements are located in the same processor
    - - 1-1 connectors
        
        connecting two elements only
      - 1-* connectors
        
        connecting one element with a variable number of elements of the same type
    - - is the implementation technology or supporting platforms of a connector's two incident elements, we classify connectors into homogeneous connectors and heterogeneous connectors
    - - implemented with the broker design pattern.
  - - - Elements
        
        Include 4
        
        Process
        
        Web services
        
        Threads
        
        Distributed objects
        
        Run on the same computer or on multiple computers across a network
        
        The same element in a code structure may implement or support multiple runtime elements
        
        Several code structure elements may implement or support a single runtime element
      - Run-time Connector Properties (Thừa kế với một số structure counterpart và với một vài thuộc tính bổ sung)
        
        Distance and connection media
        
        Hai phần tử được kết nối có thể giao tiếp trong cùng một luồng, trong cùng một quá trình, trên cùng một máy tính hoặc trên các máy tính khác nhau trên một mạng
        
        Media
        
        Đồng/quang học
        
        Wired/wireless LAN
        
        decides the system performance and reliability
        
        Universal invocable
        
        Một kết nối với thuộc tính này được đặt là đúng cho phép bất kỳ hệ thống phần mềm bên ngoài nào gọi các phương pháp tại mục tiêu của đầu nối, bất kể nền tảng phần cứng / phần mềm và ngôn ngữ lập trình
        
        Quan trọng đối với hệ thống không đồng nhất
        
        Multiplicity (Tính đa dạng)
        
        VD: Web service, client
        
        1 elements - connected - N element. Nếu nó gọi nhiều phương thức cùng lúc.
        
        Self-descriptive
        
        It allows clients to choose service providers dynamically.
        
        Một kết nối với thuộc tính này được đặt là đúng cho phép bất kỳ hệ thống phần mềm bên ngoài nào gọi method mục tiêu của nó mà không cần cài đặt trước bất kỳ phần mềm cụ thể nào cho method.
    - - specific SDLC process stages
        
        Phân tích
        
        Định nghĩa requirement
        
        Thiết kế
        
        Building or Developing the Product
        
        Testing
        
        Deployment
      - Thiết kế bởi một nhóm
        
        Use project management software
        
        Sử dụng các ứng dụng giao tiếp và thiết lập tương tác ngoại tuyến thường xuyên.
        
        Chia rõ vai trò
    - - A software project is typically implemented in multiple files. Such as: Executable files, Library files, Binary software component modules, Deployment descriptors, etc.
      - At software development time
        
        The connectors at this level are in the form of module dependency
        
        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
      - A software project is typically implemented in multiple files
        
        Executable files
        
        Library files
        
        Binary software component modules ex:DLL, Java Bean
        
        Deployment descriptors
        
        Others resources files
      - Static connector May exhibit some attributes
        
        Direction
        
        Synchronization
        
        Sequence
      - At deployment time:
        
        The elements are binary versions of the project modules and files.
        
        Several source code modules may be packaged into the same deployment unit
        
        The connectors in the deployment structures are basically the same as those for the source module structures
      - Managing Static Structural Representations
        
        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 (Tạo điều kiện cho hệ thống) construction and maintenance through a clear portrayal of intermodule relations.
        
        Involves layers of
        
        Abstraction for encapsulation
        
        Refinement showing visibility (Sàng lọc cho thấy khả năng hiển thị)
        
        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 (Chia dệ quy thành). A refinement relation specifies how a module (parent) is decomposed into a refinement module (child).
  - - - Must know what design alternatives are available to them, and which one will best support the functional and nonfunctional requirements
      - Must understand the software architecture's design space.
    - - A software element can be a package, a class, a component, or a loadable library
      - A connector can be an import clause, inheritance clause, interface specification, pipe, or filter
    - - A software element can be a process, an object, an instance of a software component, or a service
      - Different software elements may run on different hardware and software platforms and may be implemented in different programming languages or on different software frameworks
      - Two software elements can run in the same process, on the same computer system, within an intranet, or distributed over the Internet
  - - - do not emphasize the iterative refinement nature
      - waterfall model
      - do not use element and connector attributes
      - big gap between a project's requirement specification
      - if the deployment environment changes, which is happening more often with the economy's globalization, the architecture design must start from scratch.
    - - similar to current web architecture
      - refine an existing design recursively, to achieve the design objectives
      - applies the most important software architecture styles
      - thus serving as a preview before their formal treatment
    - - The architecture will then go through multiple refinement processes to support particular deployment constraints
      - the delayed binding of software connectors for more flexible implementation decisions and the seamless integration of multiple architecture styles in realizing different subsystems or levels of the same system
    - - application for serving data to a single user
      - shows a possible design, in which the client GUI module receives data retrieval criteria
      - The data retrieval & processing module retrieves data from the database following client criteria and preprocesses the retrieved data
      - These two modules are supposed to run in different threads of the same process
- - - - Class Diagram
        
        Describe each individual class with its type, interface, properties, and
        its method
        
        Provides behavioral contracts that class:
        redundancy (dự phòng), synthesis (tổng hợp) and association
        
        Typical relations including one-to-one, one-to-many, and many-to-many mappings are also denoted (biểu thị) by multiples number
        
        https://images.viblo.asia/e1f89064-9f49-40c9-82c3-2bbb40a7b390.PNG
      - Component Diagram
        
        A component is a deployable, reusable building block Used in software design and development:jar(java),ddl(.NET),...
        
        Each component has an interface to display
        its services and hide its implementations
        
        Notation: an interface is implemented (lollipops), the interface is required provided by some other component (cup)
      - Package Diagram
        
        Represented by a tagged folder indicating where it all resides classes and subpackages
        
        All classes in the same package have a unique name but they can have same name in different packages (namespace)
        
        A package diagram showing the dependency relationships between packages in that changing one package can lead to changes in other packages
        
        Using package diagrams to represent system structures can help reduce complexity and simplification of the relationships between classes
      - Deployment Diagram
        
        Describes the physical configuration of the software system deployed on the software server nodes
        hardware and network between nodes
        
        Created in the later stages of the software development lifecycle
        
        UML uses block notation to represent a computing resource node (a hardware device or a software subsystem)
        
        https://carry4ublog.files.wordpress.com/2019/04/capture-1.png
    - - Use case diagram
        
        Các thành phần chính
        
        Relation ship
        
        <<include>>
        
        [Main Use Case] --<<include>>--> [Include Use Case]
        
        mối quan hệ bắt buộc phải có giữa các Use Case với nhau
        
        <<extend>>
        
        [Extend Use Case] --<<extends>>--> [Main Use Case]
        
        mối quan hệ không bắt buộc (có thể có hoặc không) giữa các Use Case với nhau
        
        Generalization
        
        mối quan hệ cha con giữa các Use Case với nhau. Biểu thị mối quan hệ thừa kế giữa các Actor hoặc giữa các Use case với nhau
        
        child usecase --> parent usecase
        
        Communicate link
        
        cho biết actor đó có sự tương tác nào với hệ thống
        
        kết nối giữa actor và use case
        
        Boudary of system
        
        phạm vi của sự tương tác giữa usecase và actor
        
        Use Case
        
        các chức năng mà các Actor sẽ sử dụng hay thể hiện sự tương tác giữa người dùng và hệ thống
        
        verb + noun
        
        Actor
        
        được sử dụng để chỉ người dùng hoặc một đối tượng, một hệ thống bên ngoài tương tác với hệ thống
        
        Noun
        
        Biểu đồ usecase sử dụng mô tả các yêu cầu của người dùng về chức năng hệ thống (ca sử dụng) như một hợp đồng giữa người dùng (các tác nhân) và hệ thống phần mềm.
        
        https://googleentitystacking.com/wp-content/uploads/2021/07/Thiet-ke-Use-Case-mo-ta-su-tuong-tac-giua-nguoi-dung-va-he-thong.png
      - Activity Diagram
        
        Hình ảnh mô tả: https://iviettech.vn/wp-content/uploads/2014/04/Activity-Diagram2.png
        
        Các thành phần
        
        Start: thể hiện điểm bắt đầu quy trình
        
        End: thể hiện điểm kết thúc quy trình
        
        Swimlance(organization unit) , nhóm các đối tượng nào tham gia hoạt động nào trong một qui trình thành 1 đơn vị, 1 cột, hàng
        
        Transaction: thể hiện bước chuyển giao giữa các hoạt động, bước thực hiện trong 1 quy trình
        
        Activity mô tả một hoạt động, tác vụ đc diễn tả trong hệ thống. Các hoạt động này sẽ đc thực hiện bởi người, các đối tượng, các module có liên quan thực hiện V+O
        
        Decisition
        
        Branch thể hiện rẽ nhánh trong mệnh đề điều kiện (1 đầu vào nhiều đầu ra, mỗi đầu ra có 1 guard mô tả điều kiện rẽ nhánh
        
        Merge: merge nhiều đầu thành 1 đầu ra, các luồng đầu vào k cần đồng thời,
        
        Synchronization bar
        
        Fork Tách hành động, 1 hành động vào nhiều hành động ra, các hành động diễn ra đồng thời
        
        Join Gộp các đầu vào đồng thời thành 1 đầu ra
        
        Activity Diagram là bản vẽ tập trung vào mô tả các hoạt động, luồng xử lý bên trong hệ thống. Nó có thể được sử dụng để mô tả các qui trình nghiệp vụ trong hệ thống, các luồng của một chức năng hoặc các hoạt động của một đối tượng.
      - State diagram
        
        https://viettingame.com/wp-content/uploads/2021/05/state-machine-diagram-explained.png
      - Sequence diagram
        
        Các thành phần
        
        lifelines : chu kì sống, thời gian tồn tại của object theo thời gian
        
        Execution occurrence: biểu diễn thời gian một object cần để hoàn thành hành động hoặc đáp ứng 1 thông điệp nào đó đc gửi đến
        
        object/class tham gia vào quy trình
        
        Message
        
        Reply or Return Message thông điệp trả lời lại khi có request hoặc sau khi kiểm tra tính đúng đắn của một điều kiện nào đó
        
        asynchronous message bên nhận đc message có thể không cần trả lời thì vẫn có thể tiếp tục xử lý các công việc tiếp theo message(parameter)
        
        Lost and found message là trường hợp gửi đi nhưng k nhận lại đc kết quả trả vè như dự tính hoặc nhận đc nhưng k ở sơ đồ hiện tại
        
        Create message Là thông điệp được trả về khi chế tạo new một đối tượng người sử dụng !
        
        Delete Message Là thông điệp được trả về lúc xóa một đối tượng người dùng.
        
        synchronous message: yêu cầu message đc gửi đến thì cần có thông điệp trả về để tiếp tục mạch xử lý return:=message(parameter)
        
        Self message thể hiện các method trong cùng 1 object gọi lẫn nhau, cũng có thể là các hàm đệ quy
        
        Actor:người dùng hoặc hệ thống khác, là những kích hoạt hay tác động quy trình
        
        Combine fragment
        
        Alternative fragment (alt) là mô hình của cấu trúc if else
        
        Option fragment (opt) là mô hình cấu trúc switch case
        
        combined-fragment là 1 hay nhiều quá trình tuần tự trong frame
        
        Loop fragment (loop) là mô hình cấu trúc vòng lặp
        
        Sơ đồ minh họa: https://opdaichien.com/sequence-diagram-la-gi/imager_6399.jpg
        
        Sequence diagram mô tả sự tương tác của các class, các object theo thời gian
    - - UML is a typical object-oriented analysis and design notation tool that provides many useful analysis diagrams and even generates code skeleton
      - UML offers a standard way to draw a system's blueprints
      - Is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system
      - UML can be used to
        
        model the problem domain
        
        describe the user requirements
        
        identify significant architecture elements during software design
        
        describe behavior and interactions among these elements
        
        organize the software structure
        
        specify its constraints
        
        describe the necessary attributes
      - two major categories
        
        behavioral (dynamic)
        
        A dynamic software architecture describes the behavior of objects (i.e., instances of classes) in the system such as object collaboration, interaction, activity, and concurrency. The related UML diagrams are sequence diagrams, collaboration diagrams, activity diagrams, etc.
        
        structural (static)
        
        Structural software architecture describes the static structure of all software elements in a system class hierarchy, class library structure, and relationships between classes such as inheritance (is a), aggregation (has a), association (uses a), and messaging (method invocation).
      - Static structural UML diagrams depict the control flow between system elements, and are time-independent.
  - - - an extended view
      - provides a clear user-computer interface view and hides implementation details
      - provided as a series of screen snapshots or a dynamic, interactive prototype demo
    - - derives from the logical view and describes the static organization of the system modules
      - addresses the subsystem decomposition and organizational issues
      - maps software component elements to actual physical directories and files
    - - describes installation, configuration, and deployment of the software application.
      - takes into account the system's nonfunctional requirements
      - The system topology in terms of hardware, network, and other infrastructure
      - address network connections and
        communication protocols
    - - Based on application domain entities necessary to implement the functional requirements
      - an abstraction of the system's functional requirements
      - used for object-oriented (OO) modeling
      - helps to understand the interactions between entities in the problem space domain of the application and their potential variation
    - - focuses on the dynamic aspects of the system, i.e., its execution time behavior
      - looks at the system's processes and the communications among them.
      - maps functions, activities, and interactions onto runtime implementation with a focus on nonfunctional requirements as well as the
        implementation of the functional requirements
      - takes care of the concurrency and synchronization issues between subsystems.
  - - - Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle
      - Lines in the box-and-line diagrams indicate the relationship among components.
      - A box-and-line diagram can be used as a business concept diagram describing its application domain and process concepts
- - - - Encapsulation is accomplished when each object maintains a private state, inside a class
      - Other objects can not access this state directly, instead, they can only invoke a list of public functions
      - The object manages its own state via these functions and no other class can alter it unless explicitly allowed
      - In order to communicate with the object, you will need to utilize the methods provided
    - - In case of classes, abstraction can be achieved by creating an abstract class
      - It can’t be instantiated. When you want to use it, you have to let another class inherit from it.
      - abstraction is about focusing on essential qualities, rather than the characteristics of one specific example
      - Only abstract classes can contain abstract methods
      - Is an extension of encapsulation
      - Abstract methods are methods that are declared without any implementation
      - The implementation is left for child classes that inherit from the abstract class.
    - - Inheritance is the ability of one object to acquire some/all properties of another object
      - With inheritance, reusability is a major advantage. You can reuse the fields and methods of the existing class
      - The class whose properties and methods are inherited is known as the Parent class
      - And the class that inherits the properties from the parent class is the Child class
    - - each child sub-class keeps its own functions/methods as they are
      - Overloading
        
        is a way to overload methods with the same name but different parameters
        
        Method overloading is performed within class
        
        In case of method overloading, parameter must be different
      - a way to use a class exactly like its parent so there is no confusion with mixing types
      - Overriding
        
        Method overriding occurs in two classes that have IS-A (inheritance) relationship.
        
        Method overriding is used to provide the specific implementation of the method that is already provided by its super class
        
        In case of method overriding, parameter must be same.
        
        Return type must be same or covariant in method overriding.
  - - - Description
        
        In general, the functionality of an object-oriented system is encapsulated in the form of a set of objects. These objects provide different services either on their own or by interacting with other objects. In other words, a given object may rely upon the services offered by a different object to provide the service it is designed for. An object that requests a service from another object is referred as a client object. Some other objects in the system may seek the services offered by the client object.
        
        In such cases, the Interface pattern can be used to better design different service provider classes that offer the same service to enable the client object to use different classes of service provider objects with little or no need for altering the client code. Applying the Interface pattern, the common services offered by different service provider classes can be abstracted out and declared as a separate interface. Each of the service provider classes can be designed as implementers of this common interface.
    - - Description
        
        Typically a class is designed to offer a well-defined and related set of services to
        its clients. These services are offered in the form of its methods, which constitute
        the overall behavior of that object. In case of a well-designed class, each method
        is designed to perform a single, defined task. Some of these methods may use
        the functionality offered by other methods or even other objects to perform the
        task they are designed for
        
        Not all methods of a class are always meant to be
        used by external client objects. Those methods that offer defined services to
        different client objects make up an object’s public protocol and are to be declared
        as public methods. Some of the other methods may exist to be used internally
        by other methods or inner classes of the same object. The Private Methods pattern
        recommends designing such methods as private methods.
    - - Description
        
        The Accessor Methods pattern is one of the most commonly used patterns in the
        area of object-oriented programming. In fact, this pattern has been used in most
        of the examples discussed in this book for different patterns. In general, the values
        of different instance variables of an object, at a given point of time, constitute its
        state. The state of an object can be grouped into two categories — public and
        private.
    - - Description
        
        In general, classes in an application are designed to carry data and have
        behavior. Sometimes a class may be designed in such a way that its instances
        can be used just as carriers of related data without any specific behavior. Such
        classes can be called data model classes and instances of such classes are
        referred to as data objects
    - - Description
        
        Objects in an application usually make use of different types of data in offering
        the functionality they are designed for. Such data can either be variable data or
        constant data. The Constant Data Manager pattern is useful for designing an
        efficient storage mechanism for the constant data used by different objects in an
        application
        
        In general, application objects access different types of constant data
        items such as data file names, button labels, maximum and minimum range values,
        error codes and error messages, etc.
    - - Description
        
        In general, an object may need to access shared resources such as files as part
        of its implementation to provide the services it is designed for. In a multithreaded
        environment, when methods of such an object are accessed simultaneously by
        more than one thread, it could result in unpredictable behavior
        
        Instances of such
        incorrect and irregular behavior resulting from the concurrent access to an object’s
        methods by multiple threads are referred to as race conditions
        
        The monitor is a mechanism to obtain a lock on such an object to ensure that
        only one thread is allowed to execute any method on that object at any given
        time. Instead of keeping the responsibility on its client objects, the actual service
        provider object itself can be designed to be responsible to ensure that no two
        threads can execute its methods simultaneously.
        
        This can be accomplished using
        the monitor concept. In Java this can be accomplished by declaring the methods
        of an object using the synchronized keyword.
    - - Description
        
        The Abstract Parent Class pattern is useful for designing a framework for the
        consistent implementation of functionality common to a set of related classes.
        
        An abstract method is a method that is declared, but contains no implementation. An abstract class is a class with one or more abstract methods. Abstract
        methods, with more than one possible implementation, represent variable parts
        of the behavior of an abstract class. An abstract class may contain implementations for other methods, which represent the invariable parts of the class
        functionality
  - - - A class should have one and only reason to change, which means a class should have only one job.
    - - classes should be open for extension and closed to modification.
      - We should be able to add new functionality without touching the existing code for the class
    - - subclasses should be substitutable for their base classes.
      - The child class extends the behavior but never narrows it down
    - - Clients should not be forced to implement a function they do no need
      - A client should never be forced to implement an interface it doesn't use
    - - High-level modules should not depend on low-level modules. Both should depend on abstraction.
      - Interface (abstraction) should not depend on details, but vice versa. (Classes communicate with each other through interfaces, not implementations.)