Building blocks - TU/ewsinmak/Education/2IMN10/Q1_1617/Homework... · Nature of building blocks and...

Building blocks:

Connectors:

View – concern – stakeholder (1..*):

Extra-functional requirements (Y + motivation) /N :

• Security:

• Availability & reliability:

• Maintainability:

• Performance and scalability:

Distribution (Y + motivation) /N :

Clarity/Semantics ( ☺ | � | �) + motivation:

2

Building blocks:

Nodes, including disk storage, organized in racks and cabinets including storage, connected to layers

of Routers (all P)

Connectors:

Inclusion (nodes in cabinets, cabinets in pairs), communication links with protocols (VLT, ECMP)

(all P, technology mentioned)


• Physical (deployment) view.

• Interesting to system engineers, and network administrators concerned with how to build and

configure the system from its components

• And how to deploy Hadoop (where to put name nodes, job trackers)

• Interesting to data analysts using Hadoop, to see data capacity and what performance they may

expect (note that client runs within the cluster)

• Interesting to system acquirers and hardware suppliers to see what hardware to buy or supply.


• Security: N

• Availability & reliability: Y, but rather implicit,

• the cluster runs Hadoop, which ensures reliability by re-execution of failed tasks

• each pair of cabinets has two routers, i.e. two access points and there are multiple

3

routing paths

• Maintainability: N

• Performance and scalability: Y

• Metrics to indicate size of resource such as storage, bandwidth, number and type of processors

• ECMP (equal-cost multi-path routing) protocol for load-balancing network traffic

• System can be scaled up to 64 racks

Distribution (Y + motivation) /N : Y

• because there are many physical machines in this cluster

Clarity/Semantics ( ☺ | � | �) + motivation: ☺, good structure and clear legend

3

Building blocks: (all C)

A hub (broker!) providing services (lookup routing, access control, logging) , Healthcare Information

systems (QHIS), UZI-cards

Connectors:

VPN Connections from the hub to the external information systems, QHISs (C)


Logical view

• interesting for all stakeholders to that are interested in seeing how the system is organized

(patients, medical staff)

Information view (RW)

• interesting to assessors that want to check whether the system conforms to privacy regulations

regarding storage and exchange of medical data

Development view (not very convincingly)

• Interesting for programmers to see how the software within the hub is (can be) organized in

modules


• Security: Y

• Audit and access control processes, VPN to provide privacy and authorized access to

patient data

4

• Availability & reliability: N


• Performance and scalability: N,

• Although the distribution of data over QHIS is some indication of scalability, the hub may be a

bottleneck


• the data in the QH information systems is located outside the hub at the place where it is collected

Clarity/Semantics ( ☺ | � | �) + motivation: �,

• meaning of colors not explained , hence not clear

• the accompanying text on the web-site is needed to properly understand the model

4

Building blocks: classes indicating the main concepts in mitigating security risks (all C)

Connectors:

Qualified associations labelled with multiplicities, aggregations, and specializations (all C)


• Logical view, important for all stakeholders that need to understand or explain security concepts,

e.g. users, programmers, communicators


• Security: Y and N,

• Obviously the model addresses security, but it is a meta-model and does not address

a specific architecture or specific architectural elements, but identifies artefacts that should

be present

e.g. processes indicated by green classes to secure assets against risks elaborated in the red

classes.



• Performance and scalability: N

• Understandability: Y

• Model defines concepts in risk management and clarifies their relationships

5

Distribution (Y + motivation) /N :

Clarity/Semantics ( ☺ | � | �) + motivation: ☺,

• a very clear domain models for security management of business processes.

5


• processes such Client, Trackers , and processes that operate on client data (Mapper, Shuffle,

Reducer)

• storage objects (HDFS, Local)

• lifelines and activations, repetition blocks

Connectors: (all C)

• asynchronous messages (start, launch)

• synchronous messages with return values (read, write)


• Process view, interesting for testers and integrators that have an interest in putting the system

together and verifying that the parts interact in a proper fashion

• Also a scenario (of a complete map-reduce computation).


• Security: N

• Availability & reliability: Y,

• Implicitly, because Hadoop inherently addresses this issues.

• Explicitly, because we see “heartbeat” message



6

• Concurrency is visible through messages that start threads and nodes, and launch subcomputations

Distribution (Y + motivation) /N : N

Not through the diagram. Of course, it is well-known that Hadoop is a framework deployed on clusters.

Clarity/Semantics ( ☺ | � | �) + motivation: ☺

• Sequence diagram that follows the UML conventions.

6

Building blocks:

• Layers, modules, services components (all C),

• Nodes, such as mainframe running a data base, blade (P)

Connectors:

• dependencies (arrows between layers),

• control flow (horizontal arrows in damage claiming process)

• Implementation relations between services and components

• lines with filled black dots on both ends (to link roles to actors??)


• Logical view

• Stakeholders such as insurance companies and their customers can see the functionality

offered by the system

• Development view

• We see modules organized in layers, of interest to programmers and developers.

• Process view

• We see how the activity workflow of the damage claiming process. Of interest to system

integrators .

• Deployment view

• We hardware infrastucture and the services deployed on them. Of interest to system

engineers.

7


• Security: N


• Maintainability: Y

• Modular organization limits dependencies and thereby increases the maintainability



• the technology layer

Clarity/Semantics ( ☺ | � | �) + motivation: �

Much information crammed into a single model

Uses a mix of notational conventions (partly UML)

Nevertheless, it makes clear how an insurance claim is dealt with, both in terms of the process and the

organization of the software

7

Building blocks:

• threads? (C), the accompanying text suggest that we see classes for which is indicated on what

type of thread they are run

• subsystems, groups of threads that handle a specific task (the square boxes) (C),

Connectors:

• Could be flow of control or just dependencies (C)


• Logical view/development view, for all stakeholders that need to understand the system, users,

developers

• Process view, because we see processes and threads, more interesting for developers than for

system integrators


• Security: N



• Because it shows how the software is grouped into subsystems


• We see concurrency in the form of multithreading

8



Nature of building blocks and is unclear and the text on the website does not help much either.

It claims that the diagram is made “To assist others coming up to speed on the architecture of the video decoder”

It is not very successful in doing that.

8

Building blocks:

• Layers (C)

• Actors that provide content to the system (C)

• Databases, Repository (C)

• Interfaces (C, organized according to user status)

• Content management system (a server, C or P)

• Caches (P)

• Presentation blocks, GUIs?(C)

Connectors:

• data (content) flow (C),

• API calls (for policy issues, like access rights) (C)


• Development view (K & RW):

• we see layers an modules relevant for system developers, like programmers

• Information viewpoint (RW):

• we see how content providers (editors) feed data to databases and how that content gets

distributed to content consumers (internet radio stations and their audience); also we see

representation issues (XML-repository)

• Process view:

• because we can see data flow (K), ingestion of content from sources, fan-out to content

9

distributors (radio stations) and consumers (the latter via the internet)

• also mash-ups an ingest scripts are processes, interesting to system integrators


• Security: Y

• content access management in filtering and rights layer



• because the layering helps to isolate and provide separation of concerns.


• data is flattened and caches are used to provide rapid access


• but not very explicit, reading the reference this become more clear. E.g., the building blocks in the

presentation layer are clients (radio stations, listeners) that are at locations distinct from the data.


The NPR provides a central content database from which various radio stations can distribute content to their

audience using their own presentations formats. However, this

is difficult to infer this from the diagram. The pipeline architecture that shows the flow of data from content

providers to listeners and the issue addressed (COPE) is nevertheless

reasonably clear.

9


• hierarchical states, initial states

Connectors: (all C)

• labeled state transitions (labels are press button events)


Process view interesting for testers and system integrators, but also for end users (watch owners) that

can see which buttons to press, and for how long, to configure the watch.


• Security: N





Clarity/Semantics ( ☺ | � | �) + motivation: ☺-�

Complete state machine that makes it clear how to configure the watch by pushing its 4 buttons, even

though the parameters (173, 185) of function doActivity() are not explained.

Also the negated events NOTS1 and NOTS2 are unclear. Button s4 does not appear in the diagram!

10


• actors (roles, so C)

• use cases showing system functionality

Connectors: (all C)

• specialization relationships between actors

• interactions between actors and use cases

• include relationships between use cases


• Logical view that presents to stakeholders that have an interest in the external visible behavior of

the system, such as end users, acquirers,


• Security: Y

• We see an actor representing an authentication service.





11

Clarity/Semantics ( ☺ | � | �) + motivation: ☺

Conventional UML use case diagram

11

Building blocks:

• layers, nested controller modules (all C), perception subsystem (C)

• sensors, actuators (C or P: C because they are not specific, or P because they are physical

entities)

• teammates (P other identical? robots, so physical entities)

Connectors: (all C)

• uni- and bi-directional data flows, labeled with type of communicated data


• Development view: we see organization of control software in layers and modules of interest to

programmers

• Process view: we see communication between layers which is of interest for testers and

integrators


• Security: N



• Functionality is clearly located in specific layers and modules, and therefore can be

independently developed and modified

• Strict layering of low-,mid-, and high-level controllers limits dependencies.

12



Although this is the set of modules found within a single robot, we see modules that address the robot’s behavior

as part of a team. We also see communication with its teammates modelled.


Typo: temamate instead of teammate,

Not clear why communication between ZMP controllers is indicated with a double blue arrow.

Not clear which module generates the “Keyframe commands”

12

Building blocks - TU/ewsinmak/Education/2IMN10/Q1_1617/Homework... · Nature of building blocks and...

Documents

Transcript of Building blocks - TU/ewsinmak/Education/2IMN10/Q1_1617/Homework... · Nature of building blocks and...