You could use Extend in this case.
Example include and extend:
UC “login” includes UC “sign up”: The login page can be accesses straight away, but if you haven’t signed up the alt path would lead you to the sign up page . You must complete this UC to get through. You can assess the sing up page directly as well. So for reuse you could make this two use cases, instead of an alt path and include the sing up UC.
UC “edit profile” extends UC “login”: The UC “Login” always has a pop-up when you login to ask if you want to change your profile. You don’t have to do this to accesses the site. You can accesses the profile edit page from several places, with its own UC of course. You would draw this relationship as an extend because its optional to get through.
Although I generally agree with Bart van Ingen Schenau's answer, I think a few points need additional elaboration.
Th advantage of the 4+1 View Model is that it maps stakeholders to the type of information that they need, without requiring specific modeling notations to be used. The emphasis is on ensuring that all groups have the information to understand the system and continue to do their job.
The 4+1 View Model of Software Architecture was described in Philippe Kruchten's paper Architectural Blueprints - The "4+1" View Model of Software Architeture that was originally published in IEEE Software (November 1995). This publication doesn't make specific references to UML. In fact, the paper uses the Booch notation for the logical view, extensions to the Booch notation for process view and development view, calls out the use of "several forms" of developing a physical view, and a new notation for scenarios.
Instead of trying to map each of the views to particular types of diagrams, consider who the target audience of each view is and what information they need. Knowing that, look at various types of models and which one(s) provide the required information.
The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level. In complex systems, you may need a package view and decompose the packages into multiple class diagrams. In other paradigms, you may be interested in representing modules and the functions they provide. The end result should be a mapping of the required functionality to components that provide that functionality.
The process view is designed for people designing the whole system and then integrating the subsystems or the system into a system of systems. This view shows tasks and processes that the system has, interfaces to the outside world and/or between components within the system, the messages sent and received, and how performance, availability, fault-tolerance, and integrity are being addressed.
The development view is primarily for developers who will be building the modules and the subsystems. It should show dependencies and relationships between modules, how modules are organized, reuse, and portability.
The physical view is primarily for system designers and administrators who need to understand the physical locations of the software, physical connections between nodes, deployment and installation, and scalability.
Finally, the scenarios help to capture the requirements so that all the stakeholders understand how the system is intended to be used.
Once you understand what each view is supposed to provide, you can choose what modeling notations to use and at what level of detail is required. Bart's last paragraph is especially true - you can show various levels of details in your UML models by focusing on particular design elements or combining various types of diagrams into a set. In addition, you may want to consider going beyond UML to other modeling notations to better describe your system architecture - SysML, Entity-Relation modeling, or IDEF.
Best Answer
In short
Yes and no !
Yes you can model it !
The UML activity diagram models control flow and object flow. Both are very practical to model individual functions, function composition and function pipelines:
No, standard UML has no higher order functions
In standard UML, there is no simple way to my knowledge, to represent higher order functions:
Perhaps some UML guru out there could find a workaround using invocation action, invoking the functor corresponding to an object of type function. But even if it would be possible, I don't think it would be easy to understand.
Note: that the same limitation occurs for non UML models: dataflows (DFD) and also functional decomposition models (SADT) always consider activities as fixed. After all, how could you make the difference between an arrow that connects two functions, and and arrow that delivers a new function?
Conclusion
to convince yourself of the feasibility, I invite you to look at some activity diagram examples, and -- despite these were designed with a procedural approach in mind -- try to imagine how you would implement them the functional way, you'd be surprised.
For the missing higher order activities, I don't know what to advice. Perhaps make a customized UML profile to allow to visually represent the actions produced as result of actions ?