Results 1 to 3 of 3
Like Tree1Likes
  • 1 Post By Java Exam

Thread: Tutorial:Design of Software Architecture for the Java Architect Exam

  1. #1
    Java Exam is offline Member
    Join Date
    Dec 2011
    Rep Power

    Default Tutorial:Design of Software Architecture for the Java Architect Exam

    In this final article, we will look at Designing a Software Architecture in Java EE. We will first look at the analysis and design of the software architecture solution. We will look at how given a specified business problem, the architect designs a modular solution that solves the problem using Java EE. This is final part of a larger series of articles to help you prepare for the java architect exam. The most recent article looked at common java architecture, “Tutorial:Review of Java Security for the Java Architect Exam”.

    Putting the Software Architecture All Together

    There are two parts of the Java Architect exam that require you to propose a JEE-based solution to a given business problem scenario and then defend it once you have completed and submitted this design. The series of questions around your architecture are designed to discern the strengths and weaknesses of your solution to basic application functional and non-functional characteristics. We will therefore, provide a specific scenario similar in complexity as to what you can expect to receive on the exam and then step through our proposed solution for it. After providing our solution, we will consider the common functional and non-functional questions that could be asked of the solution.

    The Scenario - Chief Solution Architect

    You are the Chief Solution Architect for New Paradigm Designs Ltd, an global vertically integrated construction company with significant operations in the North America, Europe, and the Asia. New Paradigm has a supply chain for the wood, concrete and steel that it needs for it sites. It operates its own forests, quarries, and steel foundries around the globe. This vertically integrated style of operation has allowed New Paradigm to hold down its costs of raw material in an era of soaring commodity prices. However it has been obliged to build and maintain a complex back office and distribution network, which has significantly eroded the cost savings realized from its vertical integration. The New Paradigm’s management has concluded a comprehensive business-wide review of the entire company and the one compelling fact has been made apparent is that New Paradigm is using a lot of money to raw materials from storage to construction sites, even if there are suitable materials nearby.

    The decision is taken by New Paradigm management to build a new exchange dedicated to building commodities exchange for itself and a number of its competitors in order that they can effectively pool excess capacity in a coopetition model. Once completed, raw materials for any construction job can be sourced through the exchange instead of exclusively through New Paradigm inventory. New Paradigm will prioritize its own inventory for use versus the inventory of a competitor but otherwise it will use the exchange for sourcing materials. Based on management’s report and and initial interviews with key stakeholders, New Paradigm have determined the following:
    • New Paradigm has an inventory and order management system that tracks both capacity of their production facilities as well as the individual orders coming in from construction sites around the world. This system is accessed via a JMS queue. This system is a recent investment so it has a modern interface.
    • New Paradigm has decided to expose the interface to their exchange as a web services API.
    • In order to get buy in from key competitors for using the system, New Paradigm has agreed that one of the key non-functional requirements for the system will be that 95% of all transactions to and from the exchange must be completed within 5 seconds or less, and the remaining 5% must be completed in 20 seconds or less.
    • The system has an availability requirement during core working hours between GMT -8 and GMT +8 of 99.99%.
    • The process of placing products into the exchange is a manual process. It will be done by inventory managers from the different companies who will place excess product capacity into the system manually. This will allow site managers to then place bids for the product they want, with the most competitive bid winning the auction process.
    • The key users for the system are the inventory managers and site managers (i.e. buyers) for the various companies.

    Phase One - Understanding the Customers

    During this step, there are five main elements are identified and captured in the Business Model:
    1. Business Process Maps
    2. Business Processes
    3. Business Actors
    4. Customer Stakeholders
    5. Business Goals

    Experience informs us that the same logical business process is implemented in different forms at various Customers.There will be some customers that may implement the full process, whereas others may only implement a subset of it. Also different Customers may have alternative implementations of parts of the same process. The solution to adopt then is to identify in the whole system the subset that is common among all exploiters. Specifically, we identify the activities that are always performed by any Customer. These are the core business process. Optional and alternative activities can then be identified and modeled appropriately.

    Business Process Maps - they are normally represented as UML activity diagrams. They illustrate in a concise manner all of the identified business processes, and the relations among them. The processes pertaining to each organizational (business) unit are grouped in the diagram into a corresponding swim-lane. It should be noted that business processes produce and consume business entities. Starting from the map, the business processes of interest are then further detailed. The business process map can also be represented as UML activity diagrams. It could detail the Post Product, Auction and Sale business process. In a detailed business process diagram you should describe how Business Actors collaborate with one another. We have done this using a UML activity diagram to show all of the activities identified in the specific business process, in the figure below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessprocessmap.jpg
    Figure: Business Process Map with 3 Business Processes

    Business Process - they are also represented using UML activity diagrams. In the diagram above, we see how the business processes describe how the Business Actors collaborate with each other. The actions are organized into groups, which serve as a kind of packaging mechanism for organizing the responsibility for activities within a specific context. They are roles within an organization and are represented in the business process as swim-lanes. Artifacts are represented as Business Entities that are exchanged during the process as well as being associated to the activities that produce and consume them. In order to address the issue of optional or alternative activities at the business level, we advocate the Software Product Line approach. This is achieved by adding a corresponding stereotype in the activity itself to represent how the Customers are actually adopting different parts of the process.

    Each group represents activities performed by the same role within the Placement of Order space; each one of the roles corresponds to a business actor defined in the business use case model and each of the activities corresponds to a Business Use Case by means of the Business Use Case realization. Through this technique, we can now transpose the Business Processes into a Business Model and create formal traces between the two.

    Customer Stakeholders - these are a type of Business Actor. They represent the role that has ultimate responsibility for setting the Business Goals. The reason for understanding and modeling these actors and their goals is because they are normally involved in the process of construction. For example, the Inventory Manager, has set goals of ensuring that products of excess capacity are posted to the exchange within the agreed upon SLAs as well as ensuring that all transactions are completed within SLAs to satisfy outside customers. This goal, like all other goals set by the stakeholders, has to be measurable. These measures are very important to the stakeholders, and may become key information for system reports that are dedicated to them. The stakeholders may not participate directly to the business process, but will still be interested in how the business process behaves. An example of a customer stakeholder with goals is shown below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessgoals.jpg
    Figure:Inventory Manager and Business Goal

    Business Actor - they are represented along with their static relationships with Customer Stakeholders in a specific diagram using the classic Business Actor modeling elements. The modeling of the static relationships among the Business Actors is in order to capture important characteristics that help to identify hierarchies as well as for formal tracing of how they collectively co-operate to support business goals.

    Business Goals - they are used to trace back goals to a specific business use case that supports them. In UML, they are expressed using the stereotyped class with <<business goal>>.

    Phase 2 - Business Modeling

    Activities are described in business process at a very high-level. Often each activity may be done under the responsibility of the identified Business Actor although it is actually performed by several other actors, called Business Workers. You can provide more detail for each activity in the process by linking it to a Business Use Case. The realizations of the business use cases detail how each activity is performed and by which actors.

    In this phase, we complete the Business Model by the following means:
    • A use case diagram showing all of the identified Business Use Cases
    • A freeform diagram tracing the relationships among the Customer Stakeholders, the Business Goals they set, and the Business Use Cases that support those goals

    Formal traces between activities in a process and the corresponding Business Use Case Realizations are achieved by modeling such activities as Call behavior elements that link to the corresponding realizations. The Business Model resulting from the transposition of the Business Process is shown in the figure below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessmodel.jpg
    Figure:Business Model

    Similar to what was done with activities in the Business Process, Business Use Cases also can be identified as being core, optional, or alternative within the business model. During this phase, the links between the business use cases and the business goals are defined and formally expressed in UML. The tracing activity ensures that every business goal is covered by one or more business use cases. The figure below shows an illustration of this type of relationship:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessusergoalusecase.jpg
    Figure: Relationship Between Goals and Use Cases

    The figure shows this formal definition of the trace between a specific business process activity and the corresponding identified business use case. A business use case realization is used to achieve this. It will then be the means to create a link between the process and the business use cases as well as the business goals. Using this approach, one can validate the business process coverage in terms of business use cases and business goals. Once you have completed defining this part of the model, you need to perform a round of validation, involving stakeholders from the various areas. This input from various Stakeholders and potential Customers will be required in order to further refine the business model.

    Phase 3 - Business Analysis Model

    In this phase, a Business Analysis Model is developed where each business use case realization is transformed into two major UML artifacts:
    A UML class diagram showing a static view of the business use case participants (i.e. business workers and business actors) along with their relationships.
    One or more UML sequence diagrams representing a different business use case scenario or sub-process. The diagrams show the interactions existing among the Business Workers to realize the business use case.
    The Post Products business use case is realized in terms of three business workers. The Business workers are the entities that really perform the activities, while the business actors are the ones that initiate the actions and are generally responsible for their completion.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessucrelationship.jpg
    Figure: Business Use Case Realization Participants

    A business worker can be either a person or an automated system. Whenever during the realization an interaction between the business actor and a business worker that is automated, this introduces the interaction between the User and a System, which ultimately results in one or more System Use Cases. Similarly, when there is an interaction between two automated business workers, this results in a system-to-system interaction. The figure below demonstrates how the business workers of the Post Products Business Use Case Realization cooperate to implement the activity:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-postproductbusseq.jpg
    Figure: Post Products Business Sequence

    Phase 4 - Automation Selection

    This phase involves selecting the business worker(s) to be automated among the ones identified during the previous phases. This is a crucial step since it will ultimately determine the gains in productivity made through the realization of the system. There are a number of different methodologies that can used for such identification. Remember that when there is at least one business worker is automated and at least one who is not, what is actually defined is a System and its User. If, for example, New Paradigm management decides that the Post Products worker must be automated, then sequence diagram shown above provides useful information as to how to create the Post Products System Use Case model. This would imply that algorithms are being used by the various companies in order to select what products to make available on the exchange. In fact, every message arriving to the worker can be thought to become the realization of a System Use Case implementing the worker's functionality. This transposition can be done conceptually in a manner similar to what was done in the business domain to create the business use case model from the business processes. In our case, we have automated the selection of the winning bid as well as the dispatching of this information. The resulting System Use Case model after several use cases have been automated is shown in the figure below with all the identified use cases:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-systemusecase.jpg
    Figure: System Use Cases

    Phase 5 - Setup Trace Relationships

    This phase creates the traces between the business modeling and the system modeling artifacts. Best practice is to link each method provided by the to-be-automated business worker to the corresponding System Use Case realization in the system analysis model via references in the sequence diagram in order to facilitate model navigation. Also the business workers initiating these methods should be traced to corresponding system actors (User Roles) living in the System Use Case model.

    Phase 6 - Define Personas

    This phase comprises the activities that are currently considered the primary ones for creating the User Personas and understanding the User goals. The Interaction Design methodology for user modeling captures archetype Users into User Personas, along with their goals and skills. Each goal is then related to the role that the Persona interprets in a given context. For each User identified as needing a specific Interface to the product, will have a different Persona created that details the typical User's goals, tasks, and skills. The Personas are documented in a textual form in order to facilitate their communication with all of the concerned stakeholders. The figure below demonstrates one of the Personas are currently described in textual documents:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-persona.jpg
    Figure: Persona - Inventory Manager

    This creates a situation where it is difficult to trace these type of "user models" to the System Actors in the System model. In order to overcome this difficulty, a formal UML representation of the Personas is created. The formal representation of a Persona's goals, skills, and duties is introduced using the following UML artifacts.
    A UML class diagram representing the system requirements initiated by the User Roles that are modeled as User prototyped system actors named after the roles. This diagram represents the System Use Case Model.
    A UML class diagram representing the User Goals as UserGoal prototyped classes. Each User Goal will have a set of Measure prototyped measure attributes, which describe ways to measure how each goal is met. The relation between each User and the UserGoal is also captured in the diagram. The relations are dependencies between a User and each UserGoal.
    The UML class diagram mapping User Goals to User is shown in the figure below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-userusergoalpersona.jpg
    Figure: User, User Goals, and Personas

    In the figure, each Persona is shown as a class having a set of skill attributes. Each Persona is associated to all the users (User Roles) it covers, and is flagged with the stereotypes of primary persona, secondary persona, supplemental persona, negative persona, etc. This is useful to make a linkage and validate the relations between the Personas and the actual system actors that are determined (or possibly reverse-engineered) during the analysis phase. The Persona class also has attributes that capture information collected through the interviews. Besides skills, this may includes age and type of working environment. Additionally, as with other diagrams, the concept of kernel, optional, and alternative apply to the user role as well, to represent how fundamental each User Role is to the functionality of the system(s) being designed. This is useful during the prioritization of the systems' features (Use Cases). See the figure below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-traceusecaseusergoalbusgoal.jpg
    Figure: Trace Relationship for Use Cases, User Goals and Business Goals

    A UML diagram also captures the System Use Cases supporting a particular user goal. This diagram can also comprise the relations between User Goals and Business Goals, particularly which User Goals support each Business Goal. It is important to understand that this relationship must not be invented; instead it must be derived from the traces between the business model and the system model, with a reverse approach. In particular, the relationship between a specific business goal and a user goal comes out of the traces between the business use case realizations that support the business goal, and the corresponding System Use Cases that support the user goal.

    Phase 7 - System Use Case Realization

    The activities categorized as conceptual design are the usual activities of System Analysis and System Design. We completes the description of that modeling process with two other steps that help detail the functional and presentational aspects of the systems being built. During the seventh step, the system use cases are realized in two different ways, as shown in Figure 2.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-usecaserealizations.jpg
    Figure:Use Case Realizations

    The first way the system use cases are realized is via standard use case realization showing how the use case is realized through a set of cooperating classes. This is a model of the internal behavior of the system. There are two UML artifacts that model this aspect: Participants class diagram - which gives a static view of the use case participants focused particularly on the interaction between the main actor and the system involved via a boundary class. This class is normally mirrored by the main screen in the use case storyboard. One can also model explicitly this relation through a direct dependency. The figure below illustrates a Participants class diagram:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-participantsclassdiagram.jpg
    Figure: Participants Class Diagram

    Interaction diagram(s) - this is one or more UML collaboration diagrams that describes the interactions among the participants shown in the Participants Class diagram. The figure below shows the basic flow of interactions among the participants in the Post Product use case realization.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-basicinteractionflow-postproduct.jpg
    Figure:Basic Flow Post Product

    The interaction is generally between an individual and the system . In order to achieve this, the system will require a graphical user interface (GUI). In this case we have a number of options available to us such as realizing a use case storyboard similar to the traditional use case realization or developing the information architecture for the system. This part logically applies only to those parts of a system where an interaction with a person is present, which is the case at hand. If we use the information architecture we describe the flow of various parts of the system in relation to the screens.

    This becomes a reusable sequence within the overall information architecture since we have clearly delineated how the user journey will be in order to complete this use case. The figure below shows the high level information architecture for the system. We will base all use case realizations on this high level navigation.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-informationarchitecture.jpg
    Figure: Information Architecture

    In the figure below we show the flow specific to the Post Product Use Case Realization. Note that we could also achieve the same benefit using one or more UML Sequence diagrams with each one representing a different use case flow, but the benefit of this approach is that it allows one to develop a holistic view of the information architecture of the system.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-postproducthlflow.jpg
    Figure: Post Product High Level Flow

    Phase 8 - UML Storyboards

    Once the logical flow of the GUI design has been completed we need to desing the actual graphical interface. As the conceptual design is technology-neutral, we have the option of choosing between a standalone JavaTM GUI, a simple Web application, or a portlet application. Once the tradeoffs and benefits are weighed up by the key stakeholders the final decision can be taken on the technology for implementing this. At this point, this decision can be delayed and the design will remain valid.

    During the visual design phase, it is key to involve selected real and potential users to validate the effectiveness and usability of the proposal. One can choose UML
    to convey information within the technical community, while using another means to communicate key design decisions for validation to non-technical stakeholders.

    Here it is useful for non-technical stakeholders to create a visual storyboard a set of static HTML pages that the User can navigate, or even a simple prototype. The visual storyboard should be based on the User scenarios that have been identified during the Business Modeling phase and that are the core of the business processes. Using concrete scenarios of the realization of User Goals and using Personas as the actors, each visual storyboard can demonstrate how the GUI facilitates the work and productivity of the user in their task. The visual storyboards must be validated, focusing the verifications on the correctness of the main design ideas behind the GUI. The figure below shows an example of a visual storyboard:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-visualstoryboard.jpg
    Figure:Visual Storyboard

    Phase 9 - Technical Documentation

    Next we pass on to the classical technical views that must be expressed before a design is considered complete. The domain model details the main business objects that describe the overall system. This model in conjunction with the use case diagram, represents the expression of the business problem which you need to provide as a solution for Parts II and III of the exam. The domain model is shown below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-businessdomainmodel.jpg
    Figure:Business Domain Model

    Class Diagram
    Remember to ensure that all the objects detailed in the domain model are present in your class diagram. If you spot a more elegant representation of relationships, attributes, or behavior, then feel free to express your superior design, but keep in mind this is an exam scenario. You’re not trying to win over a customer with improvements in the design.

    You should select and commit to a method or framework that describes how you plan to build the system at the web/presentation, business logic, persistence, and integration tiers, but you must focus on the “how” as well as the “what.” A simple test to ensure that your class diagram captures the business IPR of New Paradigm is to explain it to yourself out loud. Name every class starting with the most important and traverse the entire class diagram using the relationships, explaining the cardinality as you go. This simple procedure will simultaneously ensure that you stay on track and focus on the solution. Remember to extend the domain model and develop all it into the associated class diagram. Key things to have in the class diagram are the following:
    The class diagram must remain web framework agnostic as one web framework is as good as another as long as the provide astandard MVC separation of concerns.
    The web and persistence framework should never detract from the domain model. This relationships and interplay is important since one of the primary purposes of the class diagram is to show the conversion of the domain model into a functioning class diagram that solves the business problem.
    If you use colors, you must provide a color key to explain the meaning of each of the colors.
    Annotations can be used to show the examiner how specific items in the domain model are mapped into JEE components such as session beans and Entity classes.
    The figure below shows an example of a class diagram derived from the domain model above:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-classdiagram.jpg
    Figure: Class Diagram

    Component Diagram
    The component diagram provides another high level view of the system in order to demonstrate your ability to visualize and understand the system at a high level including all of its constituent parts. If you have decided to use MDBs to address a difficult integration issue, then it is in this diagram that you need depict and justify your decision. The figure below depicts the component diagram for the New Paradigm solution.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-componentdiagram.jpg
    Figure: Component Diagram

    Deployment Diagram
    The deployment diagram captures information about how you intend that the system will execute at runtime in production production environment both logically and physically. You don’t need to name specific machines, vendors, or routers, but rather indicate in a vendor/machine-agnostic way the resources you need to be deployed in order to support the architecture. Depending on the environment, this could be CPUs, RAM, network requirements, disk configuration, and so on whether you are deploying into a cloud environment or a traditional hosting environment. You can setup a baseline and then run performance and load tests in order to validate your theoretical capacity prediction. In the deployment diagram for the New Paradigm system, we have adopted a standard deployment environment for an Enterprise Service Bus as we are using this component in order to facilitate interoperability with the systems of our competitors. Overtime, we will all be able to automate the placement of product on to the exchange for auction as well as manage differences in formats for key items. Note that various components such as the web/application servers require different system resources to the database tier. The resources deemed necessary will vary from one exam scenario to the next, but the fundamental resources themselves will not. The fundamental resources are the following:
    • CPUs - number of cores, clock speed
    • RAM - quantity in GB
    • Network - minimum interface speed
    • Storage - disk/SAN configuration

    Note that you are free to specify that your application will run in the cloud and explicitly design for that deployment. But remember not to compromise the exam deliverables with this choice. Even for cloud computing delivery models, the resources listed above will be required in order to know how to size your system in order to meet non-functional requirements. You will need devote the same care and attention to ensuring that your hardware and software solution is adequate irrespective of whether you adopt cloud computing delivery models or not. The deployment diagram is shown below:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-deploymentdiagram.jpg
    Figure: Deployment Diagram

    Sequence Diagrams
    You will need to supply a sequence or collaboration diagram for each specified use case. Don’t try to combine use cases in an attempt to try and save time. This will cost you on your final grade. You will not need to supply method signatures for any of the classes you define, but you are expected to supply sequence diagrams. So don’t expect the examiner to rigourously check your sequence/collaboration diagrams for correctness and syntax. You will need to have sequence diagrams that are clear and that outline the complexity of the use case being described. The classes and components you created in the class and component diagram should be represented, along with the calls between them necessary to realize the use case being documented. The figures below shows the sequence diagram mapping for the first use case: post product:

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-postproductucrealization.jpg
    Figure:Post Product Use Case Realization

    The next figure is for the sequence diagram mapping onto the second use case: bid on product.

    Tutorial:Design of Software Architecture for the Java Architect Exam-c8-bidonproductucrealization.jpg
    Figure: Bid on Product Use Case Realization

    The next figure is for a third use case Winning Bid Notification. Note that from our work there are still other use cases that you will need to cover with sequence diagrams. 
    Figure: Winning Bid Notification Use Case Realization
    Finally regardless of the level of detail or complexity that you choose to depict in your sequence diagrams, take care to ensure that the examiner can see exactly which sequence diagrams map onto the specific use cases provided.

    On Developing Your Diagrams

    A key tip for everyone taking the Architect Exam is to make it easy for the examiner to find the information required for you to pass your assignment. The keys are to do the following:
    • Ensure that all of your diagrams are legible.
    • Avoid tools making “innovative” use of JavaScript and ensure that your tool outputs static images only consistent with the explicit instructions provided on acceptable file and image formats.
    • The exam is all about solving a business problem using JEE. Make sure that the examiner can find your business solution in your diagrams. That means ensuring that he can clearly see the business logic and that any frameworks that you use are in the background.
    • Augment diagrams with English text, but make sure your diagrams are self-explanatory. The exam requires UML diagrams as part of your deliverables. So make sure that they are clear, accurate, and easy-to-understand.
    • We have provided you with all of the diagrams required to satisfy the criteria listed in the preceding bulleted list as well as key information as to how you should approach finding a solution for the exam problem. Note that I have added some novel uses of UML diagrams in order to provide clarity to the solution to the assigned business problem scenario.

    Identifying Risks and Mitigations

    As the new exam tests candidates on the JEE 5 platform, you need to be aware that the big changes wrought in the JEE platform, pushed Sun to take the opportunity to review where the old exam format and deliverables could be improved. This section was the result of that review. Here you are being tested on your fundamental architect skill (i.e. the ability to recognize the top technical risks present in your allotted business scenario and to address them in your business solution).

    Focus on being objective and strategic in assessing the risks associated with your architectural solution. You can lose marks by favoring low-level, avoidable risks over high-level, systemic risks that would create nightmare scenarios if they occurred. For example, in an online marketplace, a security compromise in any form would be a major risk. This is far more important that whether your application can run in multiple browsers or not. What you need to do is to identify risks across all potential scenarios. You will discover that the risks are quite similar. Their mitigation and complete removal, will be specific to the individual scenario.

    Defending Your Architecture

    In Part III of the exam, you are asked to defend and justify specific decisions that you made in your solution design. This is to show that you understood the business requirements, used the JEE platform in the optimal way to meet those requirements and that your proposed solution will most likely meet the requirements. You need to have a clear view of the alternatives that you considered and explain why you rejected them.

    You also need to have a clear view on the following non-functional requirements (NFRs) for the application and explain why your solution meets and or exceeds all of the NFRs::
    • Performance
    • Scalability
    • Reliability
    • Security
    • Availability
    • Maintainability

    Being able to explain your view on the NFRs will show that you understand and appreciate the key technical risks inherent in both the scenario and your proposed solution and are prepared with way of mitigating for each NFR.


    On the exam, clarity is essential. You need to make it easy for the examiner to quickly understand your proposed solution and see the logic of it.
    • While developing and documenting your solution, keep in mind the following questions: Am I providing a solution to the business problem posed, or am I solving what I want to solve?
    • Have I clearly documented my solution so that it reflects my intent?
    • Have I made my solution as simple as possible while clearly solving the business problem as presented to me in the scenario?
    • Have I third party tested my UML diagrams to ensure that they can explain it back to me?
    • The set of exam scenarios are constantly being rotated so don’t go in with preconceived notions, but instead trust your judgement and knowledge about JEE and design in general. The exam is not really on your domain specific knowledge but how you apply it within JEE.
    • Deliver your solution iin a vendor-neutral format that is readable in any browser and avoids vendor-specific extensions or file formats.
    Attached Thumbnails Attached Thumbnails Tutorial:Design of Software Architecture for the Java Architect Exam-c8-usecaserealizations.jpg  
    Last edited by Java Exam; 04-17-2012 at 12:06 PM.
    markfang likes this.

  2. #2
    arcioneo is offline Member
    Join Date
    Nov 2016
    Rep Power

    Lightbulb Re: Tutorial:Design of Software Architecture for the Java Architect Exam

    Dude, thanks for the material, I'm preparing for the exam and this is very convenient.

    Is there any way you can you upload the images with better resolution, I can see nothing even zooming them in.

    Thanks in advance

  3. #3
    FREEDOM is offline Member
    Join Date
    Apr 2017
    Rep Power

    Default Re: Tutorial:Design of Software Architecture for the Java Architect Exam

    Quote Originally Posted by arcioneo View Post
    Dude, thanks for the material, I'm preparing for the exam and this is very convenient.

    Is there any way you can you upload the images with better resolution, I can see nothing even zooming them in.

    Thanks in advance

Similar Threads

  1. Replies: 0
    Last Post: 04-06-2012, 08:24 PM
  2. Replies: 0
    Last Post: 04-05-2012, 04:49 PM
  3. Replies: 0
    Last Post: 04-05-2012, 04:19 PM
  4. Replies: 0
    Last Post: 03-30-2012, 12:28 PM
  5. Replies: 0
    Last Post: 03-24-2012, 04:22 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts