As the first part of architectural design,
a goal-oriented approach has been presented for
the process of identifying software architectural
components from the (partial) requirements description.
Now,
the second part shows a series of decomposition of the COBRA tool
in terms of its nested components. The third part shows an architectural
composition of the components using styles,
connectors, and constraints.
The last part shows how to ensure that
the architectural design is good enough concerning
the set of scenarios constructed and used to elicit, specify and
validate requirements.
The rationale for the composition is described in terms of non-funtional
requirements, domain characteristics, and the development constraints.
The process of requirements engineering and software architectural design
is an evolutionary process.
Components:
- Model Constructor = Place + Transition + Arc + Condition
[atiya, indu, jmekala & harinik]
- GUI = Basic GUI + Utilities GUI
- Basic GUI = + condition + loop + spline
[atiya, indu, jmekala & harinik]
- Utilities GUI = Move+Drag+Scale(dynamic)+Rotate+Compose/De-
+Zoom+Customizer+Font(menu)+Color
[lakshmid & ]
- Simulator = Scenario Driver + Event Gen. + Scheduler + Stat. Gen.
[atiya, indu, jmekala & harinik]
- Scenario Driver = UI Event Generator
- Event Generator = Script Communicator + Temporal Trigger + UI +
Other Internal Event Generator
- Scheduler = Queue Manager (Msg queue) + Transition Fire (currently, cyclic checking)
- Statistics Generator:
- max/min/avg number of enabled, fireable and disabled
transitions during a time interval given
- the most busy/idle states and transitions
-> dynamic reachability
- max/min/avg delay time for transition firing
(i.e., from enabled)
- number of events per category (temporal,
UI, Inter-system, Inter-Process, Intra-system)
- Given a scenario set, the Simulator constructs a simulation
model through static value assignment, which will be used
as the initial state of the model and for subsequent ones,
and dynamic event generation, which will be used to
refelect the collaborative nature of inter-/intra- system
interactions
- Animator = token flow + condition indicator + Mapper (Time+Scale)
[pi & geng]
- The Animator visually displays the sequence of state
transitions, which is generated by the Simulator,
in a most comprehensible and effective way.
This will involve mapping of the internal representation of
event tables into a conceptual, external representaion.
This will also involve visual illustration of event generation
and use (e.g., decrease in time delay, a transition action and
its triggering effect on transition conditions, message
transmission and reception).
- File Manager = File Save + Save as + File Load + File Print
[schen & zhouwei]
- The result of a session should be saved, loaded and
printed. A file save can be automatic at each time
interval given and/or manual. This module should deal with
all the attributes of all the instances of all the classes
maintained at the time of File Save/Load.
This concerns not only the APN modeling aspects but
collaborative aspects (e.g., status of communication,
coordination and negotiation) as well.
- Configuration Manager = Version Controller (Undo, Time Stamp) + System Composer
- Version Controller
- System Composer
- A system model is the result of the composition of several
sub-system models developed concurrently by the participants.
- Collaborator = Client-Server Communicator + Integrator + Negotiator
- Client-Server Communicator = Initiator + Session Manager +
Terminator
[PIPI & mingdau]
- Integrator = Model Differentiator + Concurrency Controller +
Consistency Manager
[fenny & hsin]
- Negotiator = Proposal Tracker + Argumentation Supporter
[tangh & zh]
- What and how to display exchange of knowledge:
E.g., one canvas for self, one for each external source,
and one for the integrated result, each with a different
color.
When and how to exchange knowledge:
types of metadata,
transmission of metadata - one data at a time
vs. a chunk at a time. E.g., merging a state and a
transition (color, radius, coordinate, length,
thickness).
The whole model each time or only differentials.
Message queue handler.
When and how to incorporate new knowledge:
Compute model differences, detect inconsistencies,
merge compatible differences both internally and
externally.
When and how to negotiate for coordination and conflict
resolution:
Classify types of (potential) inconsistencies, protocols
for negotiation and resolution. Even process definitions.
Classify modes of negotiation - e.g., broadcast,
one-to-one.
Allow for recording justifications leading to consensus.
Keep track of what has been resolved and what not.
- Tutor = models + scenarios + Simulator + Animator
[wang & xue]
- possibly uses pre-defined behavioral models and
typical sequences of interactions (user-system, system-system,
process-process) to help learning,
uses Simulator to populate instances and
event generations, and uses Animator to illustrate system
behavior.
Features of Tutor include:
- "replay": for both local and global actions
(e.g., communication, group discussions)
- "interactive": Tutor acts as a critique.
for both local and global actions
- "help": context-sensitive in-place display of
simple menu description and more complex
explanation.
The Generative Process
The quality of the architecture is as good as the decisions.
Rely on your intuition, consider a small number of alternatives at each decision
point, prune the tree by making informed decisions considering "-ilities",
and generate a first-cut approximation both functionality-wise and
quality-wise. Repeat the process while
making improvements by considering more alternatives and making better
decisions at various decision points by considering more "-ilities" and
perhaps a different prioritization scheme.
Decomposition of "-Ilities"
- Performance
- Time
- minimize processing time
- minimize communication time
- minimize data access time
- minimize data update/storage time
- Storage
- minimize duplication
- minimize extra information
- Maintainability
- Comprehensibility
- maximize functional independence
- maximize cohesion
- minimize coupling
- miximize the use of widely-known techniques
- optimize the size of each component
- Replaceability
- minimize coupling
- minimize data sharing
- minimize control sharing
- minimize domain assumptions
- Testability
- maximize validatability
- maximize simulation support
- maximize animation support
- maximize consistency-checking
- maximize integration testability
- miminize nesting
- maximize functional independence
- Adaptability
- maximize analyzability of impact from changes
- maximize openness
- offer several similar components (a la genetic evolution)
- Security
- minimize data sharing
- minimize the number of parameters
- minimze frequency of communication
- minimize set-valued parameters and returns
Each architectural choice can make either positive or negative contributions
towards the satisficing of non-functional requirements (NFRs).
There are two cases:
- i) Some architectural components are there specifically
for the purpose of satisficing particular kinds of NFRs (e.g., an indexing
scheme to improve time performance, an authorization scheme to improve
security, a simulation component to held understand the requirements,
a tutoring component to improve learnability, etc.);
and
- ii) A functional mapping can be evaluated against NFRs.
Guidelines:
The process of system/software architectural design can take into
consideration the following guidelines:
- separating out each of those components that would need the most coupling
into a layer somewhere <<+design simplicity,
-indirect communication overhead>>.
- place those components with high affinity to the layer components
closer to the layer.
- see if they can be merged into the same layer
- separating out each of those components that are common to all the rest
into a layer somewhere.
- group those components that would need the most cohesion in a bag
<<+design simplicity, -invisibility>>
- place the rest of the components relative to the bags according to
the degree of their affinities.
- see if some of the components can be merged into some of the bags.
- examine the presence of a transaction center or a transformation center
- identify data representations that need to be shared among components
- Consider the possibility of both main-memory and secondary-memory
residency.
- Consider architectures of
Shared Data <<+performance, -independence/modifiability>>
or Implicit Invocation <<+modifiability/enhanceability, -performance>>
(as sub-architectures)
- Consider, then, architectures of
Client & Server or
Middleware <<+interoperability, -comprehensibility>>
- see if the system has characteristics strong enough to have an overall
architectural style of:
- OO <<+info. hiding/security/modularity+methodological support,
- performance (cf. info. sharing)>>
- Structure Chart
- Event-driven: simple repository, virtual repository, BB,
- Pipe-&-Filter <<+simplicity, -performance>>:
purely sequential <+simplicity, -performance>,
concurrent <-simplicity, +performance>
- Process Control
- Client & Server: File-based, DB-based, TP-based, Groupware-based,
Web-based
- Middleware
- decide on the flow/path of data and control
- decide on the number, and types, of interfaces
An Illustration
The First Half:
Continuing the Process
The intent of the categorization is to explain why there are
non-trivial differences in the architectural descriptions of software systems
varying in size and complexity.
It would be interesting to draws an analogy between this classification and
the one in economics, namely, microeconomics and macroeconomics.
A "microscopic-architecture" refers to an architecture for a reasonably small
system with a small number of components which are small in size and low in
complexity.
For example, the KWIC system architectures can be classified as "microscopic".
An important observation here is that all components are clearly identified
together with their interactions. Additionally, every interface description is
provided for each component, along with at least an informal description of
what it does.
A "mesoscopic-architecture" refers to an architecture for a bigger system
which typically is localized geographically with little outside communication.
For example, a library system architecture might be classified as "mesoscopic",
in which the KWIC system now may become only one component of the system
Other components might include processes for check-in, check-out, fines,
new acquisition, disposal, etc.
This type of architecture may not present either
every microscopic-architectural component or every interface description.
Here, a microscopic architecture may be seen as a black-box component with
of course most/all of the interfaces, both input and output, visible from
outside. The components of a microscopic architecture would be invisible, as
wellas their internal interactions.
A "macroscopic-architecture" would refer to an architecture for a much bigger
system which can be distributed geographically with no limit on the possibly
multimodal outside communications.
For example, a library computer system - a collection of a library system,
operating systems and communication network systems - could be classified as
"macroscopic".
Consequently, the term "macroscopic" would also apply to a system any bigger
than the library computer system (e.g., a library computer system cooperating
with a publisher's computer system, a book store computer system,
a digital library computer system, an electronic commerce application, etc.).
For this type of architecture, it seems hard to present microscopic
components and interactsions. The emphasis here would be on treating
mesoscopic/macroscopic systems as units of components and analyzing their
interactions.
As with a mesoscopic architecture, a mesoscopic architecture may be seen as
a black-box component with of course most/all of the interfaces, both input
and output, visible from outside.
In terms of the level of abstraction, a "microscopic-architecture" would be
finer-grained than "mesoscopic-architecture", which in turn would be
finer-grained than "macroscopic-architecture".
In terms of the level of abstraction, a "micro-architecture" would be
finer-grained than "mesoscopic-architecture", which in turn would be
finer-grained than "macroscopic-architecture".
In other words, a macroscopic architecture represents the top level(s)
of abstraction; each component in a macroscopic architecture is represented
by a mesoscopic architecture; and each component in a mesoscopic architecture
is represented by a microscopic architecture.
This categorization seems to help us understand, for example,
why there is little interface description in CORBA and in the
7-layer protocol stack, if their descriptions are adequate, what should be
done if not.
Goal-Oriented Approach to Compositional Software Architecting
- Styles
-
- Connectors
-
- Constraints
-
- Rationale
-
My home page
Requirements->architecture
Top
COBRA Architecture