Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chap 3: Model for Software Architecture, Class diagram, Interface…

- - - - Package diagram
        
        show structure of designed system at the level of packages
        
        Package
        
        a namespace used to group together elements that are semantically related and might change together
        
        Package Import
        
        Package Merge
        
        a directed relationship between 2 packages that indicates the content of one package is extended by the contents another
      - Deployment diagram
        
        shows architecture of the system as deployment (distribution) of software artifacts to deployment targets.
        
        Artifact
        
        a classifier represents some physical entity, a piece of information that is used, produced by process, deployment, operation of a system.
        
        deployed to a node instance.
        
        standard stereotypes
        
        <<file>> - a physical file in the context of the system development
        
        <<document>> - a generic file is not a <<source>> or <<executable>>
        
        <<source>> - a source file - can be compiled into an executable file
        
        <<library>> - a static/dynamic library file.
        
        <<executable>> - a program file that can be executed on a computer system
        
        <<script>> - a script file - can be interpreted by a computer system
        
        Associations
        
        Dependency
        
        Manifestation
        
        an abstraction relationship -> represent the concrete physical rendering of one or more model elements by an artifacts or utilization of the model elements
        
        Node
        
        a deployment target which represents computational resource
        
        Device
        
        a subclass of node -> represent a physical computational resource with processing capability upon which artifacts may be deployed for execution
        
        Execution Environment
        
        a (software) node - offers an execution environment for specific types of components that are deployed on it in the form of executable artifacts
      - Component diagram
        
        shows components, provided and required interfaces, ports, and relationships between them
        
        represent: logical components (business components, process components), physical components (CORBA components, EJB components...)
        
        Component
        
        a class representing a modular part of a system with encapsulated content and whose manifestation is replaceable within its environment
        
        Component Realization White box view
        
        External view (black box)
        
        Required Interface
        
        is required by a public port
        
        designated by usage dependency from one of the classifiers realizing component
        
        designed by usage dependency from itself
        
        Provided Interface
        
        is provided by a public port
        
        realized by one of the classifiers realizing component
        
        realized directly by the component itself
        
        list of properties of a component
        
        Port
        
        specifies an interaction point => communicate with environment or internal parts
        
        Connector
        
        Delegation Connector
        
        links the external contract of a component (by its ports) to the realization of that behavior.
        
        Assembly Connector
        
        between two or more parts/ports on parts, one or more parts provide the services that other parts use
  - - - The transition links between states are solid lines with arrowheads to indicate direction.
        
        State diagrams help software developers understand how a system responds and handles external events and the corresponding event-triggering condition
        
        Has one starting point in a solid black circle and has one or more endpoints, the latter indicated by eyecircles.
      - Basic Information
        
        Widely used for embedded systems and device software analysis and design
        
        An event-oriented diagram in which the system's elements change their states in response to external or internal stimuli
        
        A state machine diagram, called a state chart in UML 1. x
        
        Ideal for specifying the internal behavior of objects
        
        A state is a rounded rectangle with three subdivisions: state name, state variables, and state activities.
        
        A state is a situation in which an object meets conditions, takes actions, and waits for a 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
        
        A complex composite state may have a subordinate state diagram. The sub-states in a composite state may be transited from one to the next, sequentially or concurrently.
    - - Use a rounded rectangle to represent an activity. Each activity diagram has a starting point and one or more finishing points. A small diamond represents a decision point in the diagram. Activity diagrams support parallel processing using a pair of black horizontal bars to indicate the corresponding fork/join actions in such pathways. UML activity diagrams also support communication between two concurrent flows by sending signals from one path to another.
      - Basic Information
        
        Typically involves complex workflow, decision making, concurrent executions, exception handling, process termination, etc.
        
        An activity diagram is a workflow-oriented diagram describing the steps in a single process. One activity diagram corresponds to one business process. There are many activities in a business process, and this diagram explores their dependency within the process.
        
        Used to describe complex business processes
    - - An activation may also branch or fork many separate lifelines for the if-selection scenario conditions; eventually all forked lines will join together
        
        A message passing action between objects is represented by a horizontal arrow link from the source to the destination.
        
        Each activation box may also have a self-recursive directed link pointed back to itself, indicating the object passes messages to itself
        
        A simple transfer message line just transfers control from one object to the other
        
        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
        
        It is represented by a solid line with an arrowhead
        
        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
        
        An object can also send asynchronous message to another object by an asynchronous message (a line with a half arrowhead).
        
        The sender of an asynchronous message can continue its work down the timeline without waiting for the return message from the target object
      - Basic Information
        
        One sequence diagram corresponds to one use case
        
        Each participant object in this diagram has a vertical timeline for its life cycle
        
        Time-oriented interaction diagram showing the chronological sequence of messages between objects
        
        Time goes forward along with the timeline downward
        
        One of the most important and most widely used UML diagrams for software system analysis and design
    - - Describe user requirements in terms of system functionality as a contract between the users (actors) and the software system
      - Include
        
        Use cases
        
        Operational work scenario
        
        use cases 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
        
        The detailed steps are specified in a separate note including the pre-and post-conditions of the action in the sequence
        
        The links between them
        
        Connection link from actor to use case shows the direction of actors using the use case
        
        An <<extend>> link
        
        Shows a newly created optional use case from an existing use case
        
        Covers alternative cases that may or may not necessarily take place
        
        A special kind of link
        
        A dashed directed line with an arrow pointing toward the extended use case
        
        An <<include>> link
        
        A special kind of link
        
        From one use case to another
        
        Indicates that the first use case reuses or includes the second use case and is needed to complete the work necessary to fulfill the requirement.
        
        A dashed line with an arrow pointing to the reused use case
        
        Actors
        
        An external “user”
        
        Human end user
        
        An application
        
        An external device
        
        Another system
      - Conclude
        
        One of most frequently used UML diagrams for object-oriented system analysis and design
        
        System analysts employ use case diagrams to capture and verify user requirements.
        
        Used in the early stages of the software development life cycle, such as analysis and design
        
        Architects and designers use these diagrams to derive structural diagrams (e.g., class diagrams) and behavioral diagrams (e.g., sequence diagrams and communication diagrams).
  - - - modeling business & similar processes
      - analysis, design & implementation of software-based systems
    - - guidance -> order of activities
      - specifies what artifacts -> developed
      - directs tasks from individual to team as a whole
      - offers criteria => monitoring, measuring products and activities
- - - - identify software modules and their boundaries, interfaces, external environment, usage scenarios...
    - - addresses nonfunctional requirements (module communication styles. performance issues at runtime)
    - - organize the software units in well-defined ways according to the actual file/directory structure
    - - specifies the deployment infrastructure in terms of software, hardware, networking configurations, installation for delivery.
    - - provides the look and feel of the system, impact other views.
- - - - The process view
        
        The software is packaged and partitioned into small units such as program libraries or sub-systems that are developed by many teams of developers
        
        Each package has its own visibility and accessibility as package or default scope visibility
        
        View addresses the sub-system decomposition and organizational issue
        
        Maps software component elements to actual physical directories, files in the development environment
        
        Modules such as namespaces, class library, sub-system, or packages are building blocks that group classes for further development and implementation
        
        UML diagrams such as package diagrams and component diagrams are often used to support this view
        
        Derived from the logical view
        
        The stakeholders of this view can be programmers and software project manager
        
        Describes the software static organization of the system modules
      - The physical view
        
        The components are hardware entities (processors), and the links are communication pathways; these together specify how the various elements such as communication protocols and middleware servers found in the logical, process, and development views are mapped onto the various “nodes” in the runtime environment.
        
        A physical view also takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), throughput performance, scalability performance, and security
        
        It is particularly of interest in distributed or parallel systems
        
        The stakeholders of this view are system installers, system administrators, system engineers, and operators
        
        The physical view shows the mapping of software onto hardware
        
        This deployment diagram shows that the order processing system is deployed on two servers
        
        It concerns itself with how to deliver the deployable system
        
        Describes installation, configuration, and deployment of the software application
      - The logical view
        
        Based on application domain entities necessary to implement the functional requirements
        
        Focuses on functional requirements and the main building blocks and key abstractions decomposing of the system
        
        An abstraction of the system's functional requirements
        
        Typically used for object-oriented modeling from where the static and dynamic system structures emerge
        
        Specifies system decomposition into conceptual entities (such as objects), and connection between them (such as associations).
        
        Helps to understand the interactions between entities in the problem space domain of the application and their potential variation
        
        Typically supported by UML static diagrams such as: class/object diagram and UML dynamic diagrams such as interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
        
        The stakeholders of the logical view are the end-user, analysts, and designers. We can apply an object-oriented design methodology in the logical view design since the view itself is object oriented
      - The process view
        
        Contributes to many non-functional requirements and quality attributes such as scalability and performance requirements
        
        A coordination view of the system's processes and the communications between them
        
        An abstraction of processes or threads dealing with process synchronization and concurrency
        
        A process is a runtime execution unit
        
        Also derived from logical view
        
        A software system can be decomposed into many such units
        
        Focuses on the dynamic aspects of the system, i.e., its execution time behavior
        
        How to organize all execution units at runtime is presented in this view
        
        The quality attributes such as performance, scalability, concurrency, synchronization, distribution, and system throughput are addressed here.
        
        Maps functions, activities, and interactions onto runtime implementation with a focus on non-functional requirements as well as the implementation of the functional requirements
        
        Takes care of the concurrency and synchronization issues between sub-systems in the system
        
        Described from several levels of abstraction, starting from independently executing logical networks of communicating programs to basic tasks running within the same processing node
        
        The non-functional requirements are also important issues the process view must address such as multi-threading, synchronous and asynchronous communications for performance and availability
        
        The UML activity diagrams and interaction overview diagram support this view
        
        The stakeholders of this view are the developers and integrators
        
        Many architectural styles such as pipe & filter, multi-tier, and others can be applied in the process view
      - The user interface view
        
        This view may be provided as a series of screen snapshots or a dynamic, interactive prototype demo
        
        Any modification on this view will have direct impact on the scenarios view
        
        An extended view from scenarios view is the user interface (UI) view giving user-computer clear interface view while hiding implementation details
      - The scenario view
        
        Provides a foundation for other 4 views and lets them work together seamlessly and coherently
        
        It helps designers discover architectural elements during design and helps to validate the architectural design afterward
        
        Describes the functionality of the system, i.e., how user will use the system and how the system provides services to the users
        
        Helps to make the software architecture consistent and validated against functional and non-functional requirements.