Software engineering is a discipline concerned with applied computer science ( computer engineering ) and business process engineering.

Software engineering is the study of methods, processes and tools to archieve successful software production and maintanance in a business context.

Software engineering tecniques are made to solve specific recurrent problems of the software production process. Therefore ignorance of these statistically leads to higher costs and lenghtned times in the software business.

A software process is not a strictly defined thing: different contexts require application of different tecniques, processes and tools in different ways. ( See differences in aircraft, game and e-commerce software markets ).

Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system. How these activities are carried out depends on the type of software being developed, the experience and competence of the developers, and the type of organization developing the software.

Requirements: descriptions of what the system should archive.

Functional requirements: specify what features the system should have and how the system should behave to serve its purpose.

Non-functional requirements: complementary to functional requirements, pose ulterior restrictions on system behaviour. They often apply to the system in general instead of very specific parts.

Requirements engineering activities: elicitation & analisys, specification, validation, documentation

Sharing architecture diagrams are a great way to disseminate info and stimulate feedback in collaborative contexts.

Critical and adaptive use ( lowering formality grade ) of design elements when employing formal design languages is essential when communicating with different classes of stakeholders. Semantic accessibility is key to communication effectiveness ( allowing parties to develop a correct, but not necessarily complete, understanding without much friction ).

Block diagrams are a good example of adaptive design language.

Architecture design is not a rigid iterative process, but more of a constrained logic inference problem ( system requirements ).

Process structure will depend on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system.

Non-functional requirements play a dominant role in shaping an architecture.

Architectural requirements may be conflicting, and thus require accepting tradeoffs. Using pattern composition and armonization is a good general way to approach the problem.

Differential analisys of an architecture against reference models can help with pre-production design validation.

[COMMENT] Krutchen "4+1" meta-architecture model is relatable. It prescribes a logical view, a dynamic view ( process view ), a concrete component-wise "business-mappable" view ( development view ), a deployment view ( physical view ), and a global aspect-associative view.

[COMMENT] Provides advice on the fundamental qualities of a good pattern description. A few patterns are presented in shallow detail: MVC, Layered, Repository, Client-Server, Pipe&Filter.

Application architectures are highly subject to reuse, because most businesses operate fundamentally in the same way and this remains true even when considering more specific classes of them.

To better illustrate the applicability of this concept seemingly different type of systems are compared: Transaction processing systems, Information Systems and Language Processing Systems.

Grammatical analisys of natural language specification, and mapping of semantic entities to object-oriented costructs.

A domain entity mapping strategy, where classes are associated to entities and definitions are inferred following use-case descriptions.

A scenario-based analisys where class definitions are determined empirically by exploring a usage scenario.

subsystem models: static models representing hierachical grouping of objects ( packages );

sequence models: dynamic models representing interactions among objects. ( UML sequence or collaboration )

state machine models: dynamic models representing how object state changes during system runtime. ( UML state diagrams )