Nato Architecture Framework (NAF) - 2 - Concepts and Elements
Jump to navigation
Jump to search
Goals of Module 2。
- To list a comprehensive, consistent and coherent series of descriptions of NNEC architecture elements as required for architecting C3 systems support
- Concepts and Elements are suitable for capturing the operational aspects essential to determine the requirements for the C3 systems support and translate these in the contents and structure of C3 systems
- Capturing architecture elements and their interrelationships have benefits:
- Capturing should be independent of their representation for various stakeholders
- Segmentation of complexity into manageable but focused descriptions
- Traceability from operational requirements to technology implementation
- A sound reasoning about the NNEC architecture elements and their interdependencies underpinning the representation for the various stakeholders.
- Linking architecture development to other NATO processes like Operational Planning and Capability Management
It is important to use the NNEC architecture elements of this as the starting point to creating views.
Scope。
NNEC Service Framework。
Operational aspect。
- is crucial to have a sound understanding of the operational domain, its structure and behaviour
- the goals and objectives of the domain
- the processes and products that are to be delivered to the environment
- the capabilities that are required for an adequate delivery of the products
- the business rules that constrain the delivery
Information aspect。
- what information is required by whom, how the information is used and created
- derived from the knowledge and insight of the operational domain.
Technology aspect。
- the operations and the required information will be supported by applications
- describe and structure the required services, applications and the underlying infrastructure
Six Capability Areas。
- Communications, Information and Integration, Information Assurance, and Service Management and Control, are linked to the NII (Networking and Information Infrastructure)
- The Communities of Interest Area relates to traditional communities, such as Land, Air, Maritime, Joint C2, Intel, and Logistics, as well as new, or ad-hoc communities of interest that may form between Nations in response to mission needs
- Users and Missions is linked to evolutionary sets of objectives expressed in terms of operational capabilities and associated concepts of operations
Top Down。
Four steps to arrive at the desired services and their internal construction (related to overarching architecture):
- Understand what NATO's mission space is all about and construct how to operate and with what to implement the operational objectives
- Derive what information is required for executing the operations and how to construct the best way of distributing and managing the information and with what to implement this;
- Derive the required automated support for handling the information and construct the best way to run and manage and implement the automated services
- Derive the required common and generic facilities for executing the automated services and construct the best way to implement and manage this infrastructure
Bottom Up。
The reasoning above can also be applied in reverse (applicable to the Reference Architecture level of descriptions):
- Understand which facilities are planned or already implemented and how they are constructed (e.g. how common and generic are they)
- Derive the automated support that can be offered to the users and where are the limitations in functionality and information handling that need resolution and construct the best way to run and manage and implement the automated services;
- Derive the information for execution the operations that can be handled by these automated services and construct the best way of distributing and managing the information and with what to implement this;
- Derive to which extend NATO's operations and objectives can be supported by this information handling
How to capture and describe architecture elements。
- captured by using artefacts:
- diagrams
- tables
- matrices
- plain text descriptions
- pictures
Methodology。
- Although best guidance to architecture development is given by a methodology the NAF does not prescribe any
- The descriptions in chapter 2 are the closest guidance the NAF can provide to the architecture development process
NNEC Architecture Concepts。
In order to develop architectures that support the NNEC transformation four concepts has been used to define and describe the relevant NNEC architecture elements
- Service-oriented development
- Component-based development
- Architecture description levels
- Quality factors
Architecture Description Levelss。
Functionality description level。
- handles all NNEC architecture elements that capture the required functionality of the considered system or aspect system.
- E.g. it contains descriptions that capture what people need to be able to do in the mission space (without stating how they need to do those things)
- it also contains descriptions that capture what the applications needs to be able to do in order to support the people in the mission space
- The functionality description level acts as the storage for requirements for each of the considered systems and aspect systems
Construction description level。
- captures how the required functionality, described in the previous description level, ideally should be constructed
- these elements are of a more compound nature, since they build on the results of the elements in the functionality description level
- The constructions captures at this layer are independent of their actual implementation
- As a sound design principle, the solutions envisioned here are not constrained by imperfect or unavailable technology
- These solutions act as the ultimate goal to strive for
- The solutions do refer types of technology required for the construction, but do not refer to actual technology products.
Implementation description level。
- handles all NNEC architecture elements that capture with what the solution is actually implemented
- reflect the feasibility of the solution
- actual technology products are considered and the consequences of their typical behaviour are taken into account
- This usually implies a reduction or limitation to the envisioned ideal solution
- This could be a temporary situation, e.g. R&D is in progress to identify the better technology, while in the meantime other, less capable technology is implemented
Quality Factors。
- For all operations, in the real world and in automated systems, there are conditions that apply on top of the actual operation that is conducted
- The fact that a task needs to be accomplished within a certain time limit possesses additional requirements to the support of that tasks
- Those conditions are also referred to as non-functional requriements
- they impose additional functionality
- E.g. the fact that information can only be accessed by a person that has the appropriate access rights implies functionality that checks these rights
- In fact, honouring these conditions determine the usability and quality of the support offered by the C3 System
- Therefore, these conditions are to be captured as Quality Factors that need to be fulfilled
- By identifying the Quality Factors in the operational domain and translating them (using the Representation paradigm) through the aspect systems down to the implementation of the technology, coherence, consistency and traceability can be reached in the design decisions made in the architecture
NNEC Architecture Elements and Descriptions。
In order to describe an NNEC architecture correctly and sufficiently the following architecture elements need to be captured. In the <<gourmet>> corresponding NMM elements has been presented.
| Chapter 3 Element | NMM | description |
|---|---|---|
| Actor | <<Node>> | who are the parties responsible for executing tasks? |
| Operational objective | <<EnterpriseGoal>> | what are the essential goals that need to be reached? |
| Capability | <<Capability>> | what abilities are required for conducting operations in order to reach desired effects? |
| Operational object | <<InformationElement>> | what entities are needed to reach the objectives? |
| Information object | <<Entity>> | what facts about the operational objects are relevant? |
| Process | <<OperationalActivity>> | what operational processes are needed and how are they orchestrated in order to deliver a desired end-state? |
| Location | <<ActualLocation>> | where do all the processes, services and activities take place? |
| Information requirement | <<Needline>> | what information is needed? |
| Business rule | <<OperationalConstraint>> | what are the conditions and constraints while delivering the endstate? |
| Information product | <<DataElement>> | what are the information deliverables? |
| Information flow | <<InformationExchange>> | What is the end-to-end chain of information between the parties? |
| User | <<ServiceConsumer>> | who are the parties that require functionality of applications? |
| Service | <<Service>> | what is the delivery of (information) products and functionality? |
| Component | <<System>> | What is the construction of services? |
| Component collaboration | <<ResourceInteraction>> | How do the components interact? |
Actor <<Node>>。
Who are the parties responsible for executing tasks?
Actor <<Node>>。
- Rationale
- it is NOT a UML <<actor>>
- allocate responsibilities in a coherent and non-conflicting manner to actual person
- first, capture responsibilities, irrespective of the actual persons or executing parties
- an actor has a certain information need
- links information requirements to the responsibility instead of to an individual
- Definition
An actor is an implementation independent unit of responsibility that performs an action to achieve an effect that contributes to a desired end state.
Actor <<Node>>。
- Objective
- to gain a thorough understanding of the distribution of responsibilities as a basis for identifying the collaborations in the organisation
- In order to arrive at interoperable parts of a larger system it is essential to start with an implementation independent description
- At a later stage of the architecture development, that will be the neutral point of reference to measure and identify the interoperability requirements
- An actor is independent of the way how the responsibilities are allocated to people or organisational units, thus establishing a single point of reference for the operational responsibilities, while allowing freedom and flexibility for different implementations
Actor <<Node>>。
- Description
- Within the operational domain, a set of independent entities are responsible for performing services in order to reach operational objectives
- These parties are called actors.
- An actor can be a consumer of a service <<Consumer>>, this is typically a role of a commander
- An actor can also be the producer of a service. This is typically the role of those that are ordered to conduct a task by a commander
- An actor can perform several roles. E.g. a commander can require a service from his subordinates but he is also delivering a result to his higher echelon commander.
- One actor role can be assigned to one or more individuals. And one individual can be assigned one or more actor roles
- There can be a conflict of interest between the responsibilities.
- Also Known As
- Business actor
- Performer
- Logical Node
- Covered aspects
- The operational aspect, since it refers to elements of the real world
- Instances of an actor are e.g. individuals or a group of individuals.
- Functional level as n actor is an implementation independent concept, depicting what the responsibility is.
Operational objective <<EnterpriseGoal>>。
What are the essential goals that need to be reached?
- Rationale
- Anything actors do - needs to contribute to the goals of the organisation
- This provides means to validate whether:
- all responsibilities and tasks of the actors indeed contribute to at least one goal of the organisation
- all goals are taken care of by the responsibilities and tasks of actors
- The operational objectives are enduring, i.e. they do not change easily over time
- Responsibilities and the tasks actors conduct are founded on the goals
Operational objective <<EnterpriseGoal>>。
- Definition
An operational objective is the intent of authority to reach a certain end state.
- Objective
To establish an enduring stable basis for identifying and defining processes and capabilities, including information needs, automated systems support, organisational structure, etc.
- Description
- all tasks and processes contribute to the operational objectives
- Operational Objectives:
- are closely linked to effects.
- are enduring overtime and are not dependent on how the organisation is structured and implemented
- give guidance for structuring and implementing matters such as required capabilities, task descriptions, processes, organisation structure
Operational objective <<EnterpriseGoal>>。
- Similar terms
- business goal
- business objective
- operational goal
- Covered aspects
- operational objective is part of the operational aspect
- Operational objective is an implementation independent
concept, describing the enduring goals of an organisation and therefore contributes to the description of the functional level
Capability <<Capability>>。
What abilities are required for conducting operations in order to reach desired effects?
Capability <<Capability>>。
- Rationale
- For achieving the goals and objectives, people need capabilities with certain functionality and implementation into resources
- Capabilities can be optimised to support the achievement of the goals and objectives effectively and efficiently
- Definition
- Capability is defined as the ability to deliver a specified type of effect or a specified course of action
- Objective
- To understand what abilities the resources (people and assets) need - in order to deliver the required effects
- Since Capability Based Planning (CBP) is crucial for the implementation of the Strategic Vision, capability management is of great importance
- As part of capability management, long-term and mid-term plans are being developed
Capability <<Capability>>。
- Description
- Delivering a specified effect requires one or more capabilities
- This means that the specified effects lead to the identification of capabilities
- Taking the scope for the architecture elements into account, two types of capabilities can be distinguished:
- operational capabilities that refer to the execution of tasks and processes, and
- system capabilities regarding the required functionality and technical infrastructure
- By analysing the responsibilities of all the different personnel, the objectives they contribute to can be established
- If conducted at the level of every individual this would be an enormous task
- Therefore roles (actors) are abstracted
- Roles (actors) are independent of the of persons that execute them
Capability <<Capability>>。
- Description
- Each actor can be linked to what he needs to accomplish, in terms of tasks with matching tangible results and effects, and the objectives these results and effects need to contribute to
- This is a top-down approach
- capture objectives
- identify required results and effects
- identify required actors
- identify required capabilities
- Covered aspects
- covers two architecture aspects: operation and (capabilities of actors), and technology (system capabilities)
Operational object <<InformationElement>>。
What entities are needed to reach the objectives?
Operational object <<InformationElement>>。
- Rationale
- In order for people to flawlessly collaborate, it is essential to have an unambiguous understanding of the things we use and communicate about
- These are to be captured by strict definitions as operational objects
- Since the objective of the description of the operational aspect is to understand the content, structure and behaviour of the Mission Space, these objects provide definitions of 'things' in the real world, and are the starting point for the informational description we seek to design in automated systems.
- Definition
An operational object is a thing or entity that occurs in the real world and of which information is required about the facts that need to be known. It can be a tangible object, like military equipment, an event such as an operation or a concept like a directive.
- Objective
- To establish unambiguous definitions for them
- Having definitions allows the different collaborating parties to refer to the exact same thing, thus enabling clear communication
Operational object <<InformationElement>>。
- Description
- The operational objects are captured as a formal specification of the entities that can exist for a considered system
- By arranging the relationships between the various operational objects consistent and unambiguous terminology is established
- The formal specification consists of a description and definition of the considered operational objects and the coherence of those definitions
- The existence of operational objects can be dependent on other objects.
- E.g. Trip is dependent on Car and Route.
- In order to define the operational objects Trip, both operational objects of which it depends need to be defined as well
- The universe of discourse determines the scope of the operational objects that need to be defined
Operational object <<InformationElement>>。
- Similar terms
- Entity
- Fact
- Business object
- Business entity
- Operational entity
- Operational object
- Covered aspects
- operational aspect
- part of the functional description level
Information object <<Entity>>。
What facts about the operational objects are relevant?
Information object <<Entity>>。
- Rationale
- Information objects represent the facts that need to be known about operational objects and their coherence, in order to turn the set of representations into information
- Information objects are the information image of events, concepts and tangible things
- The context for this information image is directly related to the operational objects described in the mission space
- Normally, not each and every detail is relevant to the considered system
- Determining which properties of the operational objects are relevant and need to be captured as data, is essential
- The considerations are guided by the context as captured in the mission space architecture descriptions
- Definition
An information object is an implementation independent representation of the facts that need to be known about objects and their coherence in order to turn the set or representation into information
- Objective
- The objective of capturing information objects is to identify and unambiguously describe all the elements of information and their properties that are relevant for execution of tasks in the mission space.
Information object <<Entity>>。
- Description
- Capturing the information objects is essential to arrive at a correct understanding of the information aspect of an architecture, thus essential for creating the correct, unambiguous and complete communication of an organisation.
- An information object provides a formal specification of the facts that are relevant to know about objects
- These specifications represent the infological relationships between information objects, whereas the definitions of objects refer to semantic relationships between objects
- Similar terms
- Entity
- Information entity
- Information element
- Covered aspects
- An information object covers the information aspect.
- Is part of the functional description level.
Process <<OperationalActivity>>。
What operational processes are needed and how are they orchestrated in order to deliver a desired end-state?
.png)
Process <<OperationalActivity>>。
- Rationale
- For the delivery of the required results and effects, there needs to be a correct supporting pattern of tasks and actions, conducted by the right types of person, with the right qualifications and abilities, using the right capabilities
- The collaboration between the types of persons, also called actors, follows a certain time-bound sequence
- This is usually referred to as a business or an operational process.
- Bases on process descriptions, specific processes can and need to be tailored for specific missions and operations
- Definition
A process is
- composition of activities
- that are triggered by an event
- and transforms a specific input into a meaningful output.
- Objective
- To understand how activities are orchestrated in order to be able to deliver the required results and effects
Process <<OperationalActivity>>。
- Description
- The process description does not refer to actual implementations (instance of a process)
- It describes the process in generic terms that can and need to be tailored to a specific mission
- Similar terms
- Business process
- Operational process
- Operational activity
- (Business) Function
- Covered aspects
- process is part of the operational aspect of an architecture
- process is part of the construction level
Location <<ActualLocation>>。
Where do all the processes, services and activities take place?
Location <<ActualLocation>>。
- Rationale
- Missions and operations are conducted from several locations
- Actors can perform their tasks and execute their processes on various types of locations
- Since actors are implementation independent, it is important to identify what possible locations where the actors perform their tasks
- Definition
A location is a geographical spot, e.g. a place represented by spatial coordinates
- Objective
- To understand where activities are executed by the actors
- The same actor can carry out the same on different locations
Location <<ActualLocation>>。
- Description
- Locations can be categorised using different types of location
- The classification can be defined based on unity of task execution, e.g. on the basis of properties relevant to the execution of a mission
Examples of type of locations are:
- Static type of location: fixes to the ground in one location over a longer period of time, e.g. NATO Headquarters (HQ)
- Deployed static type of location: operate in theatre; require stationary for operations, e.g. International Security Assistance Force (ISAF) HQ in Afghanistan.
- Deployed type of location: operate in theatre; operate while moving (can also operate be temporary stationary), e.g. aircraft carrier.
Location <<ActualLocation>>。
- Similar terms
- Location type
- Node
- Covered aspects
- the operational aspect
- construction level
Information requirement <<Needline>>。
What information is needed?
Information requirement <<Needline>>。
- Rationale
- Information needs to be presented to humans such that they can understand it
- This requires the combination, collation and exchange of elementary pieces of data into a consumable package
- This package can take any form: paper, electronic, graphical, text, voice, video, interactive 3D map, etc.
- In fact it is not the physical implementation that is most interesting, but rather understanding the required composition of the pieces of data and the quality constraints that come with it.
- Definition
An information requirement is a statement of what an actor needs to know about objects in order to fulfil his tasks in the mission space.
- Objective
- The objective of capturing information requirements is to identify the information required, and the data produced as relevant to Actors
- Furthermore, information requirements are captured to understand the requirements for the information exchange between actors
Information requirement <<Needline>>。
- Description
- Information requirements state the basic 'information functionality
- In other words, what does each actor need to know to achieve his objectives and deliver his services of the organisation?
- The information requirements description consists of the relevant pieces of information that provide certain insights to the actors inside and outside the organisation, including the basic facts these entities are built upon: information elements and their constituting information objects
- All the descriptions are produced taking into account the perspective of the actor using the information
- Therefore, the starting point of the description is the usage of that information by an actor
- Similar terms
- Requirement
- Needline
- Information exchange requirement
- Covered aspects
- information aspect
- functionality description level
Business rule <<OperationalConstraint>>。
What are the conditions and constraints while delivering the endstate?
Business rule <<OperationalConstraint>>。
- Rationale
- In order to be effective every organisation must comply with certain rules
- Those business rules indicate what kind of behaviour of the organisation is required for the realisation of the desired effects
- Business rules are the translation of the operational strategy, legislation and policies to operational guidelines and directives
- Definition
A business rule is a constraint that determines the behaviour of an enterprise while achieving its goals and objectives.
Business rule <<OperationalConstraint>>。
- Description
- Business rules exist for an organisation whether or not they are ever written down, talked about or even part of the organisation conciousness.
- It is advisable to gather business rules in formal manner
- Organisations may choose to proactively describe their business practices in a database of rules
- Capturing and implementing the business rules increase the flexibility and agility of an organisation
- In case of changes in policy or legalisation an organisation that has formalised its constraints, can adjust much faster and more effective to the new situation
- Also the impact on information systems is far more traceable.
- Serve as a sound foundation for identifying and defining quality factors for both operations (quality of operations) and information systems (quality of information and quality of service)
Business rule <<OperationalConstraint>>。
- Similar terms
- Rule
- Entity type rule
- Condition
- Constrain
- Covered aspects
- A business rule can have two perspectives: the business perspective and information
system perspective
- The business rules for the business perspective are part of the operational aspect
- whereas the business rules for the information system perspective are part of the information aspect
- BR is part of the functional description level
Information product <<DataElement>>。
What are the information deliverables?
Information product <<DataElement>>。
- Rationale
- Information needs to be provided to the actor that uses it while performing his role.
- This is conducted by delivery of information products
- Information products represent the right information in the right format, based on processing of information objects
- The processing of information objects can be calculation, collation, combination, etc.
- Information services also represent the distribution of information from the storage to the actor.
- Definition
An information product is a meaningful output comprising an implementation independent representation of required information for the achievement of goals and objectives.
- Objective
- To gain an understanding of the information required by actors and how that information needs to be delivered
Information product <<DataElement>>。
- Description
- People in the organisation need the right information delivered at the right time and in the right format
- The combination of required information at the right time and in the right format is called an information product
- What information products are needed and when these are needed depends on the processes that are executed by the actors
- Therefore it is relevant to determine at what stage of the process execution information products are required
- Each information product needs to be able to meet the Quality of Information (QoI) constraints that are linked to the information objects
- Additionally, QoI constraints need to take into account the potential distribution of people in the organisation
- Similar terms
- product
- Covered aspects
- is part of the information aspect
- part of the construction description level
Information flow <<InformationExchange>>。
What is the end-to-end chain of information between the parties?
Information flow <<InformationExchange>>。
- Rationale
- The end-to-end support for the creation of data and provision of information, determines important facets of the complete functionality of the automated information system and its technical infrastructure
- This end-to-end link does not need to be implemented as a one-to-one relationship
- In fact in a service-oriented paradigm, that is typically not the case
- However, it is expected that due to specific Quality of Information constraints, current technology requires a direct link between the users of information
- By identifying the information flows, a sound decision can be made on this issue.
- Definition
An information flow is the full chain of end-to-end information delivery from capturing, processing, and storing of data by one set of actors to processing, distributing and using information by another set of actors.
- Objective
- The objective of capturing information flows is to establish the construction of the communication patterns between groups of actors by decoupling data production from information usage
- Secondly, identifying the information flows enables the identification of Quality of Information constraints for the information delivery
Information flow <<InformationExchange>>。
- Description
- Information flows describe the patterns of communication between (groups of) actors as the chains of information delivery invocations needed in order to produce the required information
- Information flows also describe the Quality of Information constraints for the information needed by the actors in order to fulfil their tasks
- The Quality of Information for the full pattern must be consistent, where the information using actors dictate the strictest constraints that need to be met by the set of providing information deliveries
- Similar terms
- information exchange
- Covered aspects
- information aspect
- part of the construction description level
User <<ServiceConsumer>>。
Who are the parties that require functionality of applications?
User <<ServiceConsumer>>。
- Rationale
- A user can be seen as an individual or group of individuals requiring the same set of automated functionality
- In that sense the term user, that is related to automated applications) needs to be distinguished from the term actor, that is related to tasks and responsibilities
- This distinction creates flexibility in designing architectures and systems; new or other automated functionalities can be allocated to the same actor, while fulfilling its responsibilities.
- Definition
A user is a person or a group of persons representing one or more actors using the same functionality of an automated application.
- Objective
The objective is to identify the tasks related to an Actor that need to be supported by automated functionality.
User <<ServiceConsumer>>。
- Description
- As an architectural design decision, tasks performed by actors can be turned into fully automated and self-supporting pieces of software that operate without continuous human intervention
- This can typically be the case where the Quality of Information constraints are such that it is impossible for a human to meet the requirements
- However, in all cases a person will remain responsible for the execution of the automated solution and therefore needs to remain in control of the service
- Users represent those actors that actually use automated applications
- Not for the fulfilment of every responsibility an actor needs to be supported by an application
- The term user indicates that the corresponding actor is using a part of the application
- An actor can be represented by multiple users
- The opposite case is also valid; a user can represent multiple actors
- It is crucial to realise that the term user is defined form the point of view of the automated application
- Similar terms
- consumer
- Covered aspects
- technology aspect
- functional level
Service <<Service>>。
What is the delivery of (information) products and functionality?
- Operational Service
Service <<Service>>。
What is the delivery of (information) products and functionality?
- Information Service
Service <<Service>>。
What is the delivery of (information) products and functionality?
- Application Service
Service <<Service>>。
- Rationale
- Service-orientation is an important paradigm for the NNEC transformation.
- Since the descriptions of NNEC architecture elements are reflected in three architecture aspects, namely:
- the operational
- the information
- the technology aspects
- three corresponding concepts of services are identified:
- an operational service
- an information service
- an application service
- Definition
- A service is implementation independent specification of the deliverables that has added value to the consumer of that service in accordance with the customer's goals and objectives
- An operational service is a service providing an observable outcome which fulfils an operational need.
- An information service is a service providing data which fulfils information requirements.
- An application service is a service delivering automated functionality which fulfils the needs and requirements of the user, provided by an automated application.
Service <<Service>>。
- Objective
- The objective of capturing the operational services is to gain a thorough understanding of the concept of operations as a basis for identifying the collaborations in the organisation
- This understanding is independent of the way in which the operational services are implemented, thus establishing a single point of reference for the operational activities, while allowing room and flexibility for different implementations.
- The objective of an Information Service is to capture the delivery of information to actors.
- The objective to identify the application services is to support the tasks of the user.
- Each application service represents an independent and delineated piece of functionality
- The identification of application services includes the identification of domain logic, like screening rules for inputting data, and algorithms for the production of (new or updated) data.
Service <<Service>>。
- Description
- An operational service must lead up to an observable and measurable outcome
- The execution of an operational service needs to comply with quality of operation requirements
- Typical requirements are speed of execution, and adaptability to changing situations
- An information service describes the delivery of information to an actor
- For each operational service and corresponding actor, an information service describes what information is required and used in a process, and which Quality of Information constraints need to be met
- An application service describes the comprehensive set of functionalities provided in an automated fashion from the point of view of the user for a distinct task
- For each user, there will be a collection of application services based on the description of the users
Service <<Service>>。
- Added value
- Service allows:
- To create a basis for agreements with the Nations and other contributors in order
- to enable the sourcing discussion 'what does NATO need to do by itself and what could/should other parties do'
- Similar terms
- Pertaining to operational service:
- operational function
- business service
- Pertaining to information service:
- information function
- functional service
- Pertaining to application service:
- user service
- information technology service
- technical infrastructure service
- NNEC service
Service <<Service>>。
- Covered aspects
- operational service covers the operational aspect
- information service covers the information aspect
- application service covers the technology aspect
- functional description level
Component <<System>>。
What is the construction of services?
Component <<System>>。
- Rationale
- Application services are constructed by different types of components, e.g. user interface components, data access components, network components, servers, satellites
- Two types of components can be distinguished: application components and technical infrastructure components
- The combination of these application components that is selected to fulfil the required functionality is dependent on several factors
- The Quality of Service (QoS) constraints for the application services play an important role in selecting the right combination of components
- Another consideration deals with variability of implementation
- If the application service is to be used at different types of locations, this might lead to different implementations, e.g. the construction of the solution for use in a mobile situation will be different form the construction of the same application service in a static environment
- The variability of implementation needs be hidden as much possible to other components.
- Definition
- A component is the logical construction element of an elementary application service.
- An application component is a software component, whereas a technical infrastructure component is a hardware component.
Component <<System>>。
- Objective
- The objective of a component is to specify the internal behaviour and construction of each application service in order to fulfil the required functionality, taking into account the conditions and the types of resources that govern the application of the components
- Secondly, this model captures the Quality of Service (QoS) requirements the User Service needs to adhere to.
- Description
- A component describes the content and the distribution of responsibilities of application and technical infrastructure components as derived from an elementary application service
- A component encapsulates the variability in implementation
- Thus the logical and technical construction of an application service will not vary, but the implementation of a component can
- A single component can and preferably will be used in the construction of different application services
- Components have to adhere to the Quality of Service (QoS) requirements for the application services in order to meet the functionality requirements of the user
- If a component is to be used in multiple application services, the strictest QoS requirements prevail
- The Quality of Service (QoS) requirements can be determined from the Quality of Information (QoI) of the information flows by reasoning backwards from the Quality of Information (QoI) related to the delivery of the information, establishing the Quality of Service (QoS) required reaching that Quality of Information (QoI).
Component <<System>>。
- 3-tier Architecture pattern
- In principle, there are 3 types of application components that can be used to construct an elementary application service
- This is based on the common 3-tier architecture pattern:
- User interaction components: handle the interaction (input, output) with the user.
- Business Logic Components: handle the implementation of a business rule.
- Persistency Components: handle the storage and retrieval of data.
- Types of Technical Infrastructure Components
- Furthermore there are also 3 types of technical infrastructure components
- This is based on the common client-server network topology:
- Devices: infrastructure components that are intended for presenting and entering information, such as computers, satellites, handheld devices
- Network edge components: infrastructure components, such as routers, transmission equipment, and edge servers, such as proxy servers, firewalls and load balancers
- Internal network components: infrastructure components to construct internal networks, such switches or to run and maintain applications, such as web servers, application servers, middleware servers and database servers.
Component <<System>>。
- Added value
- The added value of capturing components is that it allows:
- To cater for implementation variability while keeping the logical construction stable.
- Substitution of different implementation products.
- Identification of the application of off-the-shelf hard- and software.
- To provide a comprehensive view of dependencies of technical facilities.
- To identify the quality of the technical components.
- Similar terms
- Pertaining to application component:
- web service
- software component
- user application
- Pertaining to technical infrastructure component:
- hardware component
- user device
- systems hardware
- Covered aspects
- technology aspect of an architecture description.
- construction description level
Component collaboration <<ResourceInteraction>>。
How do the components interact?
Component collaboration <<ResourceInteraction>>。
- Rationale
- Similar to the considerations for selecting the right components are the considerations for the collaboration between components
- In order to arrive at a sound construction, some specific collaboration between components can be essential, e.g. in order to execute a specialized algorithm the relevant data needs to be retrieved first
- Furthermore, it is important to identify the impact of components over the different location types on the adequate functioning of an application service of the distribution
- While identifying these collaborations, a need for additional components may occur, e.g. components that provide distribution of data
- Definition
A component collaboration is the necessary cooperation of two or more components in order to provide a required functionality
- Objective
- The objective of capturing component collaborations is to specify how the collaboration between components needs to take place in order to fulfil the functionality defined in the application services
Component collaboration <<ResourceInteraction>>。
- Description
- Component collaborations capture dependencies between components, indicating how the construction of an application service is intended to work
- There are two essential aspects that need to be captured for a component collaboration:
- Invocation: the (logical) way(s) to activate the component. This includes the data the component needs to process on behalf of the invoking entity (parameters). However, the manipulation (retrieval, processing and storage) of local data is encapsulated in the component and therefore hidden to the invoking entity
- Mechanism: the nature of the collaboration between this component and the invoking entity. The types of applied information exchange technology (interprocess communication) and communication technology are defined here.
- Since there are two types of components, two types of component collaborations are identified as well:
- application component collaboration
- technical infrastructure component collaboration.
Component collaboration <<ResourceInteraction>>。
- Added value
The added value of capturing component collaborations is that it allows:
- To provide a comprehensive view of the dependencies between the components.
- To provide a comprehensive view of shared construction elements and technical facilities.
- To provide an implementation independent specification of components and interfaces.
- Similar terms
- component interaction
- interfacing
- component data exchange
- Covered aspects
- is part of the technology aspect of an architecture description.
- construction description level.
Exercises。
Matching
|
|
|
