Development Architecture blog is designed for developers who have some troubles in their code.
This blog will be mainly on web development, though many of it's posts can be used also on software design.
I wish you nothing but the best,
The Logical View of Architecture Documentation
Architectures can be documented from several different perspectives.
Some of these are conceptual view, logical view, process view,
development view, and physical view. Choose one of these. Explain the primary documented approach (i.e. how is it represented). Discuss the advantages and disadvantages
There are several perspectives and methods for documenting
architectures. The need for documentation arises throughout the life time of a
system and it is used for specific purposes such as using the architecture as
the basis for downstream design or implementation; checking to see if design or
implementation conforms to the architecture; seeing if the architecture is
ready to support a formal evaluation for fitness of purpose; and using it to
support project planning (Nord, Clements, Emery, & Hillard 2009).
Phillippe Krutchen’s recent paper describes four main views
of software architectures that can be utilized in system building, plus a
special fifth view that ties all the other four together, i.e. the “four plus
one” approach to architecture (Krutchen 1995). The four main views are logical
view, process view, development view, and physical view.
In this article we will be looking at the logical documentation
approach. The logical view is based on the object model of the design, because
here an object-oriented design method is used. This approach focuses on the
functional needs of the system, emphasizing on the services that the system
provides to the users. In this approach, the system in question is broken down to
form a set group of abstractions, which are mostly taken as object classes or
objects, from the trouble area or domain. This break down helps to identify the
general functions or methods and elements of design across the different
elements of the specific system, as well as creates a scope for functional
analysis. They make use of the principle of inheritance, abstraction, and
inheritance (Krutchen 1995).
The Logical view is represented with the Booch approach
using class templates and diagrams (Booch 1993). Class diagrams depict a set
group of curriculum and their rational or coherent relationships, like
association, composition, usage, and so forward. Related groups of classes can
be combined together to form sets called class categories. On the other hand, class
templates take into account each class as an individual, and emphasize the
major group operations and recognize and classify the key characteristics of
In the Booch notation, only architecturally significant objects are
taken into consideration. Krutchen emphasizes the object-oriented style to
represent the logical view. He says that the principle guideline for logical
view design is to maintain a single, logical object-model across the complete
system in order to avoid untimely specialization or division of classes for
each processor and site.
Krutchen predicted an
iterative process for architectural design. It starts with describing the
critical scenarios. Next the architect can identify the key abstractions from
the troubled domain and model them in the Logical View. The logical classes can
be mapped to modules and packages in the Developmental View, and to tasks and
processes in the Process View. The process concludes with processes and modules
being mapped to the hardware in the Physical View. This shows that the four
views are not entirely independent of each other (May 2004).
However, in the architectural documentation of certain
systems, some views may be irrelevant, i.e. not all views are mandatory. The
main advantage of the Logical View is that is it mandatory for all system
documentation processes. In his paper, Krutchen says that Logical View
considers each object as active and potentially concurrent. This means that
each object behaves parallel to other objects, and more attention is given to
the exact degree of concurrency needed to achieve this effect.
This leads to
the one disadvantage of logical view, that is, it only considers the functional
aspect of the requirements.
All four architecture views are important in documentation.
The Logical view is important as it takes into account the functional
requirements of the system with major emphasis on the kind of services the
system provides for its users.
·Booch, G. (1993).
Object-Oriented Analysis and Design with Applications, 2nd ed. Redwood City,
·Kruchten, P. (1995).
“Architectural Blueprints - The “4+1”View Model of Software Architecture”. IEEE
·May. N. (2004) “A Survey of
Software Architecture Viewpoint Models”. ISO/IEC 10746 [Online]. Available:
Protecting personal data can be overwhelming, but it is not impossible. There are highly secure tools both online and offline to protect personal data. Shielding personal data can be logical, highly secure as well as inexpensive. Protecting Personal Data Offline Physically lock your financial records and personal documents in a safe place in your home. Purchase an inexpensive fire-proof safe that can be stored in a secure closet, built in your floor or wall. A good fireproof safe costs from $100 to $3000 (Sears, 2013). Protect your wallet and or purse in a desk drawer at work. Limit what you carry when you go out. Never keep your social security card in your wallet; lock it up. When filling out forms in the workplace, the doctor’s office, or your child’s school ask how your information will be safeguarded. If you do not have to fill out every little detail of your life, leave that portion blank. Ask for the consequences of not providing specific information. Shr
Behavior Driven Development, Test Driven Development, and Everything Between What is TDD (Test Driven Development) Test Driven Development was introduced by Kent Beck, in 2003. This followed the concepts of Extreme Programming, introduced in 1999 with a development experiment done by both IBM and Microsoft. The purpose of the Test Driven Development is to make sure code is clear, tested, and as redundant as possible, by making sure the tests are written first, and code is being added to "fill the blanks". Every code iteration needs to pass all tests (may those be unit tests, integration tests, data integrity tests, or UI tests). Writing the tests first allow us to see what fails, how, and allow us to visualize the structure of our code, by making sure each test is performed to test a specific, extremely defined sub-section of a feature. Let's assume a "BasicMaths" class, to perform simple mathematics operations. [TestClass] public class Uni