Embedded Files
- The Context Diagram graphically depicts the information flows between the current process, product, system or application and necessary internal and external vendor systems in the target environment.
- This model originated from the classic structured analysis work done in the late 1970’s by Tom DeMarco and Ed Yourdon.
- In addition to providing a better understanding of the existing environment, this model can assist in:
- Communicating the scope of the current process
- Identifying potential project stakeholders
- Validating existing “interfaces” or information flows
- The Context Diagram is the top level of a hierarchical collection of Data Flow Diagram.
- Circle (in the center) : The system to be developed, thought as a business process. It is the Machine where the area of major concern.
- Arrow: The data flows into or out of the process.
- Box: A source or sink that is the originator or receiver of system data. It is the Application Domain which shall be structured into separate individual Domain.
- The Context Diagram should be the 1st representation of the Problem Context.
- It gives the developer an opportunity to to structure the Problem Context as a number of separate Domains,
- Together with the Machine the developer intends to build,
- To show how the Domains interact with each other and with the Machine.
- The structuring of the Problem Context is the essential 1st step,
- Towards problem analysis, and
- Towards the choice of appropriate Problem Frames.
- It gives the developer an opportunity to to structure the Problem Context as a number of separate Domains,
- Context Diagram Examples:
Documenting Software Architecture:
- What Software Architecture is, and Why it's Important to Document it:
- Different Views of Architecture:
- View
- Logical
- Process
- Physical
- Development
- Software
- Description
- Addresses the static design model.
- Addresses the design's dynamic view.
- Addresses how the software components are mapped onto the hardware infrastructure.
- Represents the static organization of the software components in the development time environment.
- What to document?
- System Context:
- The system context documents how the entire system, represented as a black box, interacts with external entities (systems and end users).
- It also defines the information and control flows between the system and the external entities.
- Architecture Overview:
- It illustrates the main conceptual elements and relationships in an architecture through simple schematic representations.
- Architecture Overview diagrams include an Enterprise View and an IT System View.
- The overview helps to represent the business and IT capabilities required by the organization.
- An architecture overview also provides high-level schematics that are further elaborated and documented in the functional and operational architectures.
- It depicts the strategic direction the enterprise is taking as it pertains to IT systems.
- It illustrates the main conceptual elements and relationships in an architecture through simple schematic representations.
- Functional Architecture:
- Also known as the Component Architecture, or model, the Functional Architecture artifact is used to document how the architecture is decomposed into IT subsystems that provide a logical grouping of the software components.
- It describes the structure of an IT system in terms of its software components with their responsibilities, interfaces, static relationships, and the way they collaborate to deliver the required functions from the component.
- This artifact is developed iteratively through various stages of elaboration.
- Operational Architecture:
- The Operational Architecture artifact represents a network of computer systems that support some of the performance, scalability, and fault tolerance (among others) requirements of the solution.
- It also runs the middleware, systems software, and application software components.
- The Operational Architecture artifact represents a network of computer systems that support some of the performance, scalability, and fault tolerance (among others) requirements of the solution.
- Architecture Decisions:
- The Architecture Decisions artifact provides a single place where all the architecturally relevant decisions are documented.
- Decisions are typically about but not limited to:
- The structure of systems.
- Identification of middleware components to support integration requirements.
- Allocation of functions to each architectural component (architectural building block).
- Allocation of architectural building blocks to the various layers in the architecture.
- Adherence to standards.
- Choice of technology to implement a particular architectural building block or functional component.
- Decisions are typically about but not limited to:
- Any decision considered architecturally relevant to satisfy the business and engineering goals is documented.
- Documentation usually involves:
- Identification of the problem.
- Evaluation, including pros and cons, of various solutions.
- Selected solution, including adequate justification and other relevant details that would help downstream design and implementation.
- Documentation usually involves:
- The Architecture Decisions artifact provides a single place where all the architecturally relevant decisions are documented.
- Developing the System Context:
- System Context Categories:
- Users and Roles:
- These artifacts show the users and roles that interact with the system.
- A description of the role and the context in which it accesses the system.
- A description of the information for which the role accesses the system.
- The volume of transactions that a typical user in a given role would be performing in a given unit of time.
- These artifacts show the users and roles that interact with the system.
- Channels:
- Users will use different channels to access the system.
- Create a separate subsection to document this channel information.
- Documentation for each of the channels should minimally capture:
- A description of the channel and the type of roles or users that typically use it to interact with the system.
- The network and bandwidth supported by the channels.
- The access protocol to send and receive data to and from the system.
- Users will use different channels to access the system.
- External Systems:
- A descriptive overview of the external system, including background information about the placement of the system in relation to the system to be built.
- The access protocol required to interface with the external system, such as secure HTTP, sockets, a proprietary access mechanism, and so on.
- The data formats supported or expected by the external system to facilitate integration.
- Any specific compliance requirements that need to be followed in order to interact with the external system.
- Nonfunctional specifications of the system, such as security, availability, information throughput, and so on.
- Users and Roles:
- System Context Categories:
- Develop the Architecture Overview
- Enterprise Architecture Diagram:
- Users and Delivery Channels
- Core Business Processes
- Data and Information
- Technology Enablers
- Layered Architecture View:
- Enterprise Architecture Diagram:
- Functional Model Overview:
- Functional Modeling, also called Component Modeling, focuses on building the functional architecture of the system
- by breaking the problem domain into a set of non-overlapping and collaborating components.
- Logical Level Design:
- Subsystem Design:
- Component Design
- Specification Level Design:
- Component Responsibility Matrix
- Interface Specification for Components
- Identifying and Sssociating Data to Subsystems
- Component-Interaction Diagram
- Physical Level Design:
- The physical-level design essentially revolves around distributing the application and subsystems on preliminary nodes,
- so they can be installed and run on physical hardware nodes that collectively represent the infrastructure topology of the system.
- The physical-level design is also used to influence technical infrastructure and other middleware components and subsystems.
- Logical Level Design:
Page updated
Google Sites
Report abuse