Copyright: I don’t have anything. This is only my resume to OCMJEA 6 study based on Bambara’s book (an excellent one, buy it if you can here). All the images are from that book and from Google Images. Personal use only. Sorry for english errors. Sergio Figueras (sergio@yourecm.com).

The introduction of all OCMJEA 6 content is Application Design Concepts and Principles. What does this mean? In this section we’ll learn how Object Orientation techniques impacts in our JavaEE projects. The principal characteristics that we’ll gonna study are: encapsulation, inheritance, use of interfaces, separation of concerns, how separation of concerns works in JavaEE service layers, including component APIs, run-time containers, operating systems, and hardware resources, and how non-functional and quality-of-service requirements that influence application design, including trade-offs in performance, availability, and serviceability.

1. Encapsulation

Encapsulation means pack or restrict methods and data in a single component, or “as it in a capsule”. So, the behavior and data of some classes can kept hidden for other classes that uses this one. We can do this with access modifiers (protected, private) in variables and methods. Let’s give a little example: if you are using a motor to your main project, you don't need to know how every step of that motor works, you only need to use it. In other way, it would be painful to learn all the commands of some class and after use it. Encapsulation reduces the software complexity and increase robustness because the programmer can limit interdependencies between classes. See the encapsulation example below and note how “salary” variable is encapsulated:

2. Polymorphism (IS A Relationship)

Polymorphism is referred in biology as a capability of organisms or species have multiple behaviors. We’ve this in OOP too. Subclasses can share superclasses methods and have their methods at the same time. In a relation like SchanuzerDog extends Dog, every schnauzer inherits bark() method, but they have their own methods too. One of the best cases one can make for using polymorphism is the ability to refer to interfaces rather than implementations. In the following example, we’ve three different bikes with three different implementations of the same method of their superclass.

3. Delegation

Delegation is not a pattern, it’s a design concept. Inheritance and delegation are discussed in the famous GoF book, but not as a pattern. The delegation is the act of delegate an action to some other class do. Let’s think about the ignition and the motor. You’ll tell to the ignition to turn on the car, but the ignition will first of all tell to motor turn on the car. So in this case, we’ve ignition as the delegation and motor as delegate. Delegation is useful when you want to hide some complexity of your code in some situations. We use it if there’s no inheritance between the delegate and delegator classes.

4. Coupling

Coupling is a metric that defines how much a class is “de-coupled” from others and how focused they are, so it means: if we change so much this class, this class will impact in many others? Classes must have low coupling to increase manuteintability. Think of a combo audio system: It’s tightly coupled because if we want to change from analog to digital radio, we must rebuild the whole system. If we assemble a system from separates, it would have low coupling and we could just swap out the receiver. “Loosely” coupled features (i.e., those with low coupling) are easier to maintain. Interfaces are a powerful tool to use for decoupling. Classes can communicate through interfaces rather than other concrete classes, and any class can be on the other end of that communication simply by implementing the interface. A loosely-coupled class can be consumed and tested independently of other (concrete) classes.

5. Cohesion

Cohesion is a measurement that defines how much the class is coherent to their responsibilities and no one responsibility. For example, a class that threats some data and URLs is not coherent, because it's treating something else of it's scope. Any class must be highly coherent. Think of a machine that washes both clothes and dishes—it’s unlikely to do both well.2 At the other extreme, a class that parses only the punctuation in a URL is unlikely to be coherent, because it doesn’t represent a whole concept. To get anything done, the programmer will have to find other parsers for protocol, host, resource, and so on. Features with “high” coherence are easier to maintain.

6. Separation of Concerns (SoC)

Separation of concern is the act of separate all the distinct concerns in distinct sections.  A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors, for example: if a authentication system has a feature of recover password by email, that concern should be divided as little as possible. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).   So, every unit into the system needs to have a clearly defined responsibility and functionality. This applies to all levels of system. Every unit that have a clearly defined responsibility and functionality is a concern.

7. Non-functional Requirements (NFRs)

Non-functional requirements are requirements that guides all the aspects of how your application should response in some situations, example: need to permit 200 concurrent users logged in and all transactions must respond in only 150ms. Here we can see a table with some NFRs.

7.1 Security

Are considered aspects of Security NFR:
 – Privacy: prevent information disclosure by non-authorized access.
 – Integrity: prevent data modification or corruption by non-authorized access.
 – Authencity: proof that a person was correctly identified or a message is transmitted as received.
 – Availability: ensure that services, informations and equipments are available for use.

8. Tiers

Tiers are the logical or physical components according the hierarchy of service. The tiers can consume data from the next tier. For this exam, we’ve the following tiers:
 5. Client tier: This tier embraces display data to the client. It uses for example HTML and Javascript.
 4. Web/presentation tier: Manages users sessions and routes the requests and responses. It can be interpreted like a waitress.
 3. Business tier: Manage transactions and execute all the business logic.
 2. Integration and middle tier: Consumes external resources, normally in behalf of business tier.
 1. Resource or database tier: Databases, flat data sheets, and everything that is a parameter to integration tier.

9. Project Lifecycle Workflow

Project Lifecycle workflow is the workflow of understanding what a project is. A simple project has two basic phases: planning and executing. In the following picture we can see the normal project workflow likes:

The RUP (Rational Unified Process) is a kind of project lifecycle workflow, it splits all projects into phases and iterations. Each phase should delivery a product (something that can be tested according to requirements) and iterations are organized according the risk associated with them (most dangerous comes first). Also, start and end dates are also required by RUP. There are four base phases for every project in RUP:

Every phase has it own workflows and their workflows have their own specific activities. Every activity involves workers and artifacts. Workers are everyone which does the work. And artifacts are every tangible information produced by an activity, so we can say that an Artifact is a result for a Activity. Artifacts can be documents, diagrams and 

10. How Object Oriented principles impacts systems architecture?

Object Oriented principles can reduce costs of JEE projects in the following way:
 – Maintainability and Adaptability: maintainability is increased because it's easier to work when SoC is implemented. It’s easier to write new requirements and it's easier to adapt some code if it is necessary. It's easier to create new features since the interfaces have been not changed.

11. Differences between Tiers and Layers

Tiers are the scope where layers run. For example, Client tier run on client computer, Web tier runs on the web server, and so on. Layers can be defined as a pattern where components of each layer uses the services of the layers below. Layering helps maintainability. What determines how well an application can be parted between tiers is how they layers works. Those are the layers that you need to know for your certification:
 – Application layer: it’s the application containing business rules, normally .war or .ear files.
 – Virtual platform: contains REST, WebServices or servlets to access application layer.
 – Application Infrastructure (containers): Contains products that provides uses to application (WebSphere, JBoss, etc).
 – Enterprise services (OS and virtualization): Operating systems that runs our application infrastructure (Linux, OS X, etc) and the database software that runs on our storage layer.
 – Compute and storage layer: consists of our hardware.

So, we’ve the following order from top to bottom:
VIRTUAL PLATAFORM can call
APPLICATION LAYER can call
APPLICATION INFRASTRUCTURE can call
ENTERPRISE SERVICES can call
COMPUTE AND STORAGE LAYER.

10. Objects and so on

Objects are a junction of a STATE + BEHAVIORS that runs on our RUNTIME. All the objects have an UNIQUE identity and are a instance of ONLY ONE CLASS.  And every objects are UNIQUE.
Classes provides the metadata and methods implementation for objects and constructors to initialize attributes at creation time. A constructor is a method that contain instructions to initialize the object.

10. UML (Unified Modeling Language)

Are artifacts generated of UML language:
 – Use Case diagram: represents the high-level behaviors that a system should do given a specified actor.
 – Class diagram: Represents system classes and their relationships.
 – Object diagram: Represents a snapshot of a class instantiation.
    – State machine diagram: represents a set of states that a object can experience and the triggers that transition from one to other state.
 – Communication diagram: represents the diagram of objects working together to create some behavior.
     – Sequence diagram: represents a time-snapshot oriented perspective of a communication diagram.
 – Activity diagram: represents the flow of some activities that should be performed by an actor or a system.
 – Component diagram: represents physical components and their interrelationships.
 – Deployment diagram: represents how software components should be distributed between the hardware nodes.
 – Package diagram: represents a set of diagrams or any modeling elements.
 – Interaction overview diagram: presents how the diagram fragments interacts.
 – Timing diagram: represents time duration and constraints between time events.
Are example of relationship used in UML the following:

10.1 Use Case Diagram

10.2 Class Diagram

10.3 Package Diagram

10.4 State Diagram

10.5 Activity Diagram

10.6 Sequence Diagram

10.7 Collaboration Diagram

10.8 Component Diagram

10.9 Deployment Diagram