Functional View

• Functional viewpoint uses Component Model to describe the system’s functional aspect.
• Component Model is a formal representation of the internal Structure of the solution Static View, and solution Behaviour, i.e. Dynamic View.
• It is the next step of the System Context Diagram that aligns with the Black Box engineering principle to the White Box principle.
• Using Black Box engineering principle, we focus on what the components or interfaces offer.
• Think of a component as a black box with cohesive functionality.
• Functional aspect is also called as white box engineering.
• We group together the requirements into different components.
• Helps in making following decisions
• Where should the components run?
• Where should the components’ data be?
• Where should the components be installed?
• How will the components communicate with each other?
• Components invoke each other, offering and requesting information via “messages” that flow between them.
• This approach is at the heart of SOA or API Integration architecture styles.
• It's elaboration increases the level of completeness.
• It's refinement increases the level of precision.
• It's implementation takes place between the logical and physical levels.
• Logical components are implemented by physical components.
• Component capabilities are modeled in terms of what they can do, the activities they can perform.
• Modelling the functional aspect
• Component and Service modelling
• Reasoning about the structure and behavior of the system as a set of interrelated and interacting Components.
• Components capabilities are modeled in terms of what they can do, the activities they can perform, and the information they are responsible for.
• Components work together through the exchange of information via interfaces.
• Components can manifest themselves as Services that are accessible through their interfaces or APIs that are exposed via a contract.
• A component is a modular unit of functionality.
• A Component is a primary concept used for describing the functional aspect of the IT architecture
• A component makes its functionality and state available through one or more interfaces.
• Component Modeling includes following steps
• Component identification
• Review architectural patterns, reference architectures, and reusable assets derive an initial set of components.
• Partition into subsystems and components and assign functional responsibilities
• Identify interfaces to external systems.
• Identify components for architecturally significant use cases.
• Structure ensuring loose coupling, high cohesion, and other good qualities
• Partition the system into subsystems and components and assign responsibilities based on an analysis of the requirements.
• Use a reference architecture, architectural patterns, and other reusable assets that can be used as a starting point
• Ensure the components are 
• Highly cohesive
• Cohesion is a measure of the strength of the dependencies within a component.
• Responsibilities contribute to a few related business activities only.
• Responsibilities are likely to use the same input or output data.
• Responsibilities are likely to be used together.
• High Cohesive is a good component.
• It should be able to be independently hosted and deployed.
• Loosely coupled
• Coupling is a measure of the strength of the dependencies between component.
• There is no unnecessary inter-component communication.
• Communication is via fundamental data types.
• If communication is via composite data, then it is self-describing data, such as XML.
• If two components depend on each other, it is better to merge them.
• Less coupling is always better in a component
• We should check based on domain objects and not their identifiers
• For example, to check a supplier, we should not check if it's ID is present. In fact, we should check for the entire supply object.
• Also, supply details should be separated from supplier creation.
• Well isolated
• Isolation is a measure of the degree to which product and technology dependencies are isolated.
• Product and technology dependencies are decoupled.
• Patterns, such as the Gang of Four, Proxy, Bridge, and Mediator are used.
• Technological aspect should not be embedded into logical aspect/functional aspect.
• Technological aspect should not be created as a service.
• Right granularity
• Granularity is a measure of the size or amount of functionality assigned to a component.
• It should an autonomous business concept or business process or business component.
• Component models should not be of so high value that they become unrelated to the functionality.
• Component models should not be at low levels that they become over related to the functionality
• Layered according to their generality.
• Layering involves separating out components according to their generality.
• Layering provides a logical partitioning of components into a number of sets or layers.
• Rules define relationships between layers
• In Strict rules Components only depend on components in the same layer or the one below.
• In Non-Strict Components may depend on components in any lower layer.
• We can restrict inter-component dependencies.
• Well-layered systems are more loosely coupled.
• Layers are basically used to tag a group of components.
• Examples of layers can be Business processing layer, Business services layer, Middleware layer, System software layer.
• Tier is a physical tier for example, Database tier, UI tier.
• We should identify components for architecture. Significance use case
• This is a use case which touches majority of components, functionally, or non-functionally.
• If in this flow of architect, significant use case, if something is missing, then flow is incomplete.
• After the completion of this step we get following products
• An initial set of components with associated responsibilities.
• This is documented as Component or Service Catalog.
• One or more component relationship diagrams showing dependencies between components.
• One or more component interaction diagrams showing collaborations between components.
• Component specification
• Specify interfaces
• Defining component interfaces by separating out the responsibilities placed on the components
• Approaches to identifying interfaces on IT components
• Use case define what services component can do, which helps us to identify interfaces.
• Use case helps us to identify interfaces on IT components
• Data model also helps us to define interfaces based on data consumed and released by component.
• Approaches to identify business service component interfaces from business entities
• Produce a logical data model showing business entities.
• Identify core business entities.
• Create interfaces and operations to manage core business entities.
• Supplier, order, customer, product can be our data/business entities.
• Information models are used to identify component interfaces
• For each industry, we have domain data models.
• Specify operations and signatures
• For each interface, specifying the operations and their signatures, that is, parameters passed and return values
• Specify pre- and post-conditions
• For each operation, specifying its contract of behavior or pre- and post-conditions
• Specify services of the component in terms of method/API.
• The interfaces define inputs and output of the component.
• Define responsibilities of the component.
• Interfaces are dependent on the layer which we are working.
• Determine pre and post condition of service.
• Layering involves separating out components, according to their generality.
• Layering influences what kind of component will get propagated in which component.
• One layer is dependent on other, which helps in separating out components.
• For each operation identified, decide what data flows in and out to provide the required functionality.
• Look for collaborations between components in component interaction diagrams.
• Create structured data types as appropriate.
• After the completion of the component specification we have a refined component model with
• Defined component interfaces based on the responsibilities placed on the components.
• Specify the operations and their signatures, that is, parameters passed and return values.
• Specify the contract of behavior or pre and post conditions.
• Component implementation:
• Define implementation approach, make realization decisions
• Identify products and packages
• Components that are to be implemented using commercial-off-the-shelf (COTS) products, should be mapped to the specified-level components to the appropriate products or packages.
• Identify the approach to implementation by defining the physical-level components.
• Use patterns or other assets to help in this definition.
• Enterprise Architectures frequently adopt the Reuse before Customise before Buy before Build guideline.
• We make a decision on the technology of the components.
• During component implementation, the logical-level model is transformed into a physical-level model.
• Implementing a specified-level component model into a physical-level component model involves
• Selecting products and packages
• Identifying frameworks and patterns
• Deciding what components have to be developed
• Making choices about what technology should be used to realize the components
• There can be more than one physical component model for each specified-level model.
• Component Examples
• Static, structural views and dynamic, behavioral views
• Application level
• Business processing components
• Business service components
• Application Components implement a specific business function within the IT system example capturing Due Diligence information
• Technical level
• Technical components
• System software components
• Hardware components
• Technical Components are not associated with business functions.
• They play a technical role that supports use of other components.
• Logical level
• Focuses on the functional responsibility and purpose of the solution components without being concerned of their implementation
• Physical level
• Represents actual concrete software or hardware technology, a product/package used for component implementation.
• Data modelling
• Reasoning about the structure and relationships between the system’s information entities.
• Data modeling is a key part of information architecture, which also considers the informational parts of requirements,operational, and viability aspects.
• Use of Functional View
• Application development or customization
• Work allocation
• Version control
• Design strategy
• Reuse
• Testing
• Project management
• Product or Package selection
• Operational perspective
• Deployment of components
• Operations
• Systems Management
• Services and components are interrelated
• Components offer and request services via their Service Interfaces or APIs.
• Services are satisfied by components which request services from other components.
• Components may be grouped into subsystems
• We can create functionalities by integrating these subsystems, for example, supplier due diligence verification.
• A logical group of any number of any model elements.
• Model elements can be simultaneously in any number of subsystems.
• A subsystem has no intrinsic capabilities; it is simply an identifier.
• It helps us to label major parts of an IT system.
• It helps us to identify a commercial software product or package, such as CICS or SAP
• Helps us to allocate work to development groups.
• A subsystem does not have its own interfaces.
• Interfaces are actually interfaces on components in the subsystem.
• Unified Modeling Language is one of the notations used for Component Modeling
• It is a graphical notation, supported by a single metamodel, for describing software systems.
• It is an open standard controlled by the Object Management Group (OMG)
• Based on a unification of the modeling work of Grady Booch, Jim Rumbaugh, and Ivar
• Jacobson.
• It is a popular formal notation in software engineering and architecture which is supported by a large number of tools.
• A component modelling can foucs on functional aspect as a
• UML class notation
• Describes the system's internal structure as a Component Rrelastionship diagram.
• Also called as collaboration diagram.
• UML sequence diagram
• Describes the system's behaviour using Component Interaction diagram.