Bear in mind that we are in the process of developing a framework and not an application - There are many differences to set aside when it comes to certain concepts in general - when you google them, the technical terms may have different meanings. In that sense, you may like to get into the stupid social media framework of the Facebook and look at their TAM! LOL.
I told, things are getting straight forward - they will. (The different set of Actors)
The Technology Acceptance Model (TAM) is definitely evolves during the bottom up process and it is mainly used to define the ACTORS. It deals directly with the scientific efforts of data scientist who have tried to make sense of the status or behavior of something, somewhere, a natural order or a community of people, etc.
- The dots that connects the business rules of natural environment
- The dots that connects the business rules of built environment
- The dots that connects the business rules of Iranian people water centric framework
- The dots that connects all the above together
I'll already got to the point that illustrates the IMPOTANCE of TAM during the "Requirement Analysis" phase during the Technology Transition Model (TTM) developments, again - the concept in general may depict a different meaning for a reader familiar with terms by google it - what!
Now, that we have our set of Actors scientifically approved, to play their role, we get into developing the INTERACTION, BEHAVIOURAL and STATUS diagrams to end the "Requirement Analysis" phase easy - with no complications. Why no complications! Ask your senior requirement analyst to explain!
I will start with the hints to help the "Design, Development and Test" iterative and incremental life cycles - Hints for a full SDLC to be outlined. It is very important to define Diagramming Guidelines for the Framework.
The guidelines presented in this framework, could be applicable to all types of diagrams, UML, or otherwise. The terms "symbols, dot lines and labels" may be used throughout:
- Symbols represent diagram elements such as class boxes, object boxes, use cases, and actors
- Dot lines represent diagram elements such as associations, dependencies, and transitions between states
- Labels represent diagram elements such as class names, association roles, and constraints
Other types of guidelines may include: Readability, Simplicity, Naming and General. Guidelines for Common Framework Modeling Elements may include: Guidelines for Framework Notes, Framework Stereotypes, Framework Frames and Framework Interfaces.
- Framework Use-Case Diagrams include: Use-Case, Actor, Relationship and System Boundary Box Guidelines.
- Framework Class Diagrams include: General, Class Style, Relationship, Association, Inheritance, Aggregation and Composition Guidelines.
- Framework Package Diagrams include: Class Package Diagram, Use-Case Package Diagram and Packages Guidelines
- Framework Sequence Diagrams include: General, Guidelines for Lifelines, Message and Guidelines for Return Values
- Framework Communication Diagrams include: General, Message and Link Guidelines
- Framework State Machine Diagrams include: General, State, Substate Modeling, Transition and Action, Guard Guidelines
- Framework Activity Diagrams include: General, Activity, Decision Point and Guard, Parallel Flow, Activity Partition (Swim Lane) and Action-Object Guidelines
- Framework Component Diagrams include: Component, Dependency and Inheritance Guidelines
- Framework Deployment Guidelines include: General, Node and Component, Dependency and Communication-Association Guidelines
- Framework Object Diagram Guidelines
- Framework Composite Structure Diagram Guidelines
- Framework Interaction Overview Diagram Guidelines
- Framework Timing Guidelines include: General, Axis and Time Guidelines
To be continued in part 8 ...