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:
- Business Process Maps
- Business Processes
- Business Actors
- Customer Stakeholders
- 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:
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:
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:
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:
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.
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:
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:
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:
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:
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:
￼Attachment 3570 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.
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:
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.
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.
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.
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:
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:
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:
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.
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:
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:
The next figure is for the sequence diagram mapping onto the second use case: bid on product.
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.
- 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::
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.